2011-05-12 3 views
1

런타임 성능면에서 보면 Java에서 int를 short로 변환하는 것이 얼마나 비쌉니까? 그러한 주조가 수천 개있을 수 있으므로 성능에 영향을 주는지 아닌지 궁금합니다. 감사.int에서 Java로 short 형으로 변환하는 것이 얼마나 비쌉니까?

+4

빠른 간단한 벤치 마크를 통해 질문을 해결할 수 있습니다. 나는 당신이 그 성능에 대해 너무 걱정하지 않아야한다고 생각합니다. –

+1

응용 프로그램에 따라 다릅니다. –

답변

6

아니요. 성능에는 영향을주지 않습니다. 이것은 하나의 간단한 조작입니다. 소프트웨어의 성능을 분석하려면 입력 크기에 따라 알고리즘 연산의 계산 비용에 더 중점을 둡니다.

+0

@bvdb : 유감스럽게도 답변이 제대로 표시되지 않아 삭제할 수 없습니다. 나는 대신에 코멘트를 게시해야했다. – Heisenbug

+0

죄송합니다. 과도하게 공격적인 댓글을 삭제하겠습니다. :) 어쩌면 나는 나쁜 날을 보냈습니다. – bvdb

3

캐스팅 비용을 무시할 수 있습니다. 당신은 그러한 캐스트의 수천을 통지하지 않습니다.

1

성능 문제가 발생할 때까지 성능에 대해 걱정하지 않는 것이 안전하다고 생각합니다. 성능 문제가 발생하면 대부분의 비즈니스 응용 프로그램에서 대다수의 응용 프로그램 부진이 디스크 및/또는 네트워크와의 상호 작용에서 차지할 가능성이 매우 높습니다. 나는 이것이 마이크로 최적화가 당신의 성능에 많은 영향을 미칠 것 같지는 않다.

+1

나는 성능에 유의하기를 좋아한다. 성능을 고려한 개발자 또는 동일한 이유로 인해 발생한 버그로 인해 너무 많은 코드를 수정해야했습니다. –

+0

최적화 영역을 밟지 않고 성능을 유지하는 간단하고 안전한 방법이 있습니다. 예 : 루프 내에서 임시 객체를 생성하지 않아도되므로 오토 박싱을 피할 수 있습니다. 최적화가 반드시 마지막 일이며 가능하면 완전히 피하는 것이 좋습니다. 코드가 기능적, 유지 보수 가능 및 정확하고 최적화 된 것보다 낫습니다. – locka

+2

@ 존 - jvm이 런타임에 코드를 최적화하는 방법을 아주 잘 이해하지 못한다면 대부분의 마이크로 최적화가 기껏해야 추측이라고 주장 할 것입니다. – DaveH

1

왜이 작업을 수행해야합니까? 나는 훨씬 성능에 영향을 것이라고 생각하지만, 데이터는 당신이 필요로하는 입력의 마음에 범위를 유지하지 않습니다

int: -2,147,483,648 to 2,147,483,647 
short: -32,768 to 32,767 
0

캐스팅 메모리에서 INT를로드하거나 짧은 저장에 비해 작다. 어쨌든 그들은 모두 약 2 나노 초의 비용이 든다. 이러한 작업을 수천 번 수행하면 몇 초가 걸릴 것입니다.

1

다음은 긴 케이스의 테스트이지만 짧게 조정할 수 있습니다. int를 long으로 변환하는 것은이 예제에서 long을 전달하는 것과 비교하여 약 5 % 더 느립니다.

흥미롭게도 암시 적 캐스트를 사용하는 메서드를 호출하는 것은 느리게 수행하는 것이 좋습니다. PT0.141517096S 캐스트 : PT0.148024511S 암시 적 캐스트 : 없음 캐스트와

PT0.159904349S

@Test 
public void testPerformance(){ 
    long sum =0L; 
    long timeCallWithImplicitCast =0; 
    long timeCallWithLong =0; 
    long timeCallWithCast =0; 


    for(int j=0;j<2;j++) {//First run warm-up 
     timeCallWithCast=0; 
     timeCallWithLong=0; 
     timeCallWithImplicitCast=0; 
     for (int i = 0; i < 10_000_000; i++) { 
      long s1 = System.nanoTime(); 
      sum += shift(i);//Call with int implicit cast 
      long e1 = System.nanoTime(); 
      timeCallWithImplicitCast += (e1 - s1); 
     } 
     for (int i = 0; i < 10_000_000; i++) { 
      long s3 = System.nanoTime(); 
      sum += shift((long) i);//Call with cast long 
      long e3 = System.nanoTime(); 
      timeCallWithCast += (e3 - s3); 
     } 
     for (int i = 0; i < 10_000_000; i++) { 
      long l = (long) i; 
      long s2 = System.nanoTime(); 
      sum += shift(l);//Call with long 
      long e2 = System.nanoTime(); 
      timeCallWithLong += (e2 - s2); 
     } 
    } 
    System.out.println("With no cast  : "+ Duration.ofNanos(timeCallWithLong)); 
    System.out.println("With cast   : "+Duration.ofNanos(timeCallWithCast)); 
    System.out.println("With implicit cast: "+Duration.ofNanos(timeCallWithImplicitCast)); 

} 

protected long shift(long index){ 
    return index << 4; 
} 
+0

마침내 어떤 종류의 "증거"가있는 대답. – bvdb

2

filosophical 인수 따로 변명을 떠나 ... 모든 short

우선 특수 데이터 형식입니다. 자바는 short을 정말로 좋아하지 않습니다.JVM 스택이 32 비트 레지스터을 사용하기 때문에 자바는 실제로 int을 사랑합니다. short은 16 비트 데이터 유형 (int = 32 비트)입니다.

32 비트 구조 때문에 Java가 스택을 short로 이동할 때마다 자동으로 스택이 정수로 변환됩니다. 그래서, 궁금해 할 첫 번째 일은 정말로, 내가 자바에서 short을 사용하고 싶습니까? 그들은 실제로 비용을 지불합니다. 따라서 jdk 소스 코드에서 short 데이터 유형을 거의 볼 수 없습니다.

JVM은 정수를 short로 변환 할 때 i2s 조작을 사용합니다. 정확한 비용은 사용중인 JVM과 하드웨어에 따라 다릅니다.

in this paper의 통계를 찾을 수 있지만 불행히도 i2s은 표시되지 않습니다. 그것은 20ns 미만 걸릴해야합니다.