Joebak's blog

Many people use 'substring' method. I found many people simply use 'substring' method in String class. I was wondering substring of String class cause overhead. so i decompiled String.class. public String substring( int beginIndex) { if (beginIndex < 0 ) { throw new StringIndexOutOfBoundsException (beginIndex); } int subLen = value . length - beginIndex; if (subLen < 0 ) { throw new StringIndexOutOfBoundsException (subLen); } return (beginIndex == 0 ) ? this : new String (value, beginIndex, subLen); } You can see 'new String()' code at the end of the function. Every time new instance created when it called. The HackerRank Problem is below. https://www.hackerrank.com/challenges/reduced-string It is better to use 'StringBuffer' then 'String'. Below is deleteCharAt method of 'StringBuffer'. public AbstractStringBuilder deleteCharAt( int index) { if ...

이펙티브 자바 8장을 사내 스터디를 위해 정리하다가 정리해두면 좋을 정보를 블로깅합니다. (모두가 알고 있는 내용이지만 발표를 위해 직접 테스트까지 해서. 그냥 지우기 아까워서 ㅋㅋㅋ)  -> (비교 연산이 목적이라면) 객체화된 reference type 대신 primitive type을 이용하라.  -> 비교연산이 아닌 Method 의 경우라면 신중하게 고민 후 선택하라. !. 속도차가 많이 나기 때문이다. 속도차가 나는 이유. 1. Heap 메모리 할당 비용이 크다. primitive type 인 변수 n1 는  stack에 저장 된다. reference type인 n2는 stack에 저장되지만,  heap 메모리도 할당 을 받는다. 1.2. Stack과 Heap은 운영체제 (JVM) 에서 처리하는 방식도 다르다. 운영체제에서  두 메모리 저장 장소를 처리하는 방식의 차이가 있다. stack은 비교적 예측 가능한 크기의 메모리가 할당되고 , Heap은  가변적 크기의 메모리가 할당 된다. 또 Heap보다  Stack이 캐싱될 확률이 높다 . 아래는 메모리 사용량을 테스트 하는 코드이다. primitive type인 'double' 사용 결과: Used memory: 692160 reference type인 'Double'을 사용. 결과: Used momory: 1384336 reference type이 메모리를 많이 잡아먹는 것을 확인헀다. 이제는 속도를 비교해 본다. Eclipse 마켓에 있는 'JBenchX' 를 사용하여 Benchmark를 했다. 단순한 연산 10,000 개를 벤치마크한 ...

'Effective Java' 8장을 보면 이런 문구가 있다. 그러나 네이티브 메서드를 통해 성능을 개선하는 것은 추천하고 싶지 않다. 통상, 네이티브 메서드(c, c++로 만들어진 API를 호출)는 성능향상을 위해 사용한다고 알고 있다. 그렇다면 네이티브 메서드를 통해 왜 성능 개선을 하지 말라는 것일까? 먼저 'Java Performance' 라는 위키를 본다. http://en.wikipedia.org/wiki/Java_performance 흔히 자바는 느리다고 생각한다. 왜냐하면 JVM 위에서 돌아가기 때문에 직접적으로 CPU를 컨트롤하는 C, C++에 비해 느리기 때문이다. 맞는말이다. 하지만 현재의 JVM에는 틀린 말이다. 왜나하면 JIT (Just-In-Time Compilation) 을 통해 드라마틱한 성능향상이 있었기 때문이다. (1997/1998 Java 1.1에서 첫 소개) 이전 블로깅 글 (' Android 가 어찌 이리 빠른 성능을 낼 수 있는가? ' ) 에 JIT을 간과했을 때 생기는 부끄러움이 생기는 것을 경험해봤다. * JIT 보다가 흥미로운 점 발견. compile tpye이 -client, -server로 나뉘는데 말그대로 -client는 어플리케이션 용도, -server는 서버 용도이다. client는 GUI 우선순위를 좀 더 두고,  server는 순전히 성능에만 초점을 둔 각자 다른 binary file을 사용 한다고 함.  * JIT 컴파일러는 는 인터프리터, 컴파일 두가지 속성을 다 가지고 있다. 필요할 때만 .class파일을 읽는게 아니라, 자주 사용하는 .class의 경우  machine code를  생성해 두고 컴파일된 형태로 계속 사용 한다. (재생성하지 않고 재사용한다.) http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#c...