길이가 1까지 카운트하는 것과는 대조적으로 0으로 카운트 다운

Question

길이가 1에서 카운트하는 대신 길이가 1에서 0까지 으로 작은 루프를 카운트하는 것이 좋습니다입니까? 다운

for (int i = a.length - 1; i >= 0; i--) { 
    if (a[i] == key) return i; 
} 

2) 계산 첫번째 약간 빠르다

for (int i = 0; i < a.length; i++) { 
    if (a[i] == key) return i; 
} 

카운트 업

1)이 두 번째 (제로에 비교하여 더 빠른)하지만 약간이므로 내 생각에 오류가 발생하기 쉽다. 게다가 첫 번째 JVM은 향후 JVM의 개선으로 최적화 될 수 없습니다. 그것에 대한 아이디어가 있습니까?

Answer 1

변수에 a.length의 결과를 저장하면 실제로 더 빠르지 않습니다. 어쨌든, 그러한 사소한 작업의 성능에 대해 걱정할 필요는 거의 없습니다. 방법의 가독성에 중점을 둡니다.

나를 위해 카운트 업이 더 읽기 쉽습니다.

Answer 2

이와 같이 너무 많은 변경 작업을 수행하기 전에 이것이 성능 문제임을 나타내는 벤치 마크가 있는지 확인하는 것이 좋습니다. 나는 어느 날 가장 읽기 쉽도록 갈 것입니다 (제 의견으로는 위쪽에 세는 사람이 하나 있습니다).

마이크로 최적화를하고 컴파일러가 올바른 일을하도록 신뢰하지 않는다면 간접 참조를 피하기 위해 두 번째 루프의 변수에 a.length를 캐싱하는 것을 고려해야합니다.

Answer 3

제 생각에는 선제 적 최적화보다 규칙 및 가독성 (이 경우 카운트 업 방식)을 선호하는 편이 낫습니다. Josh Bloch에 따르면 최적화가 필요하다고 확신 할 때까지 코드를 최적화하지 않는 것이 좋습니다.

Answer 4

한 가지 방법과 다른 방법을 비교하는 이유가 있다면 (목록에있는 항목의 순서를 말함) 규칙에 따라 매듭을 풀지 마십시오. 쪽으로); 그렇지 않은 경우 - 다음 사람이 쉽게 일할 수 있도록 협약을 맺으십시오. 아래로 계산 정말 걱정 안 int로 비교 대 0으로 비교

...

Answer 5

은 하나의 기계 코드 명령을 드롭 할 수있는 가능성에도 불구하고, 느린 경향이있다. 현대에서는 성능이 그렇게 간단하지 않습니다. 컴파일러는 순방향 루프를 목표로 최적화를하므로 역순으로 루프를 최적화하지 못할 수도 있습니다. 캐시 하드웨어는 일반적인 정방향 검색을 위해 설계되었습니다. 이런 종류의 미세 최적화에 대해 걱정할 필요가 없습니다 (그리고 정말로 필요한 상황에서 자신을 발견한다면).

Answer 6

"조기 최적화는 모든 악의 근원"이라고 Donald Knuth는 말합니다. "우리는 작은 효율성을 잊어 버려야합니다.

이 경우 필자는 가능한 성능 향상은 가독성의 손실 만보다 클 것이라고 주장 할 것입니다. 프로그래머 시간은 CPU 시간보다 훨씬 비쌉니다.

추신 : 성능을 향상 시키려면 부등호 테스트를 고려해야합니다. 하지만 빈 배열에주의하십시오.)