1. 자바에서 파일 쓰기 구현시 어떤 방법이 빠른지 테스트.
- FileWriter fw = new FileWriter(LOG_HOME+"writer.log");
- BufferedWriter bw = new BufferedWriter(new FileWriter(LOG_HOME+"writer.log"));
- FileOutputStream fos = new FileOutputStream(LOG_HOME+"outputstream.log");
- BufferedOutputStream fos = new BufferedOutputStream(
new FileOutputStream(LOG_HOME+"bufferedoutputstream.log"));
- FileChannel fc =
(new FileOutputStream(new File(LOG_HOME+"filechannel.log"))).getChannel();
// Byte Buffer 매번 생성
- FileChannel fc =
(new FileOutputStream(new File(LOG_HOME+"filechannel.log"))).getChannel();
// ByteBuffer 재사용
2. 테스트 결과
1K 2K 5K 10K 50K
FileWriter 31 32 94 203 1281
FileWriter + BufferedWriter 15 31 94 188 1000
FileOutputStream 32 47 109 188 1063
FileOutputStream + BufferedOutputStream 31 47 109 203 1578
FileChannel 47 63 109 219 2906
FileChannel + Byte Buffer 재사용 31 47 188 250 2766
FileWriter와 FileOutputStream의 성능이 높게 나옴.
BufferedWriter 등의 경우 GC를 유발하는 문제가 있기 때문에 성능 저하 요인이 될 수 있으나, 테스트 결과로는 FileWriter + BufferedWriter의 경우가 성능이 제일 좋음.
Android - 웹뷰 성능 향상
1. 캐쉬 사용하지 않기
webView.getSettings().setCacheMode(WebSettings.LOAD_NO_CACHE);로 브라우져 캐쉬를 끈다.
2. 하드웨어 가속 기능 사용하기
렌더링에 대해서 하드웨어 가속 기능을 사용할지 여부인데, 3.0 부터 지원.
default는 false이며, 4.0부터는 default가 true.
AndroidManifest.xml에서 android:hardwareAccelrated를 true로 설정
3. 렌더링 우선 순위 높이기
강제적으로 렌더링 기능에 대한 우선 순위를 높이는 방법이다.
webView.getSettings().setRenderPriority(RenderPriority.HIGH)로 설정
API Level 18부터는 deprecated.
webView.getSettings().setCacheMode(WebSettings.LOAD_NO_CACHE);로 브라우져 캐쉬를 끈다.
2. 하드웨어 가속 기능 사용하기
렌더링에 대해서 하드웨어 가속 기능을 사용할지 여부인데, 3.0 부터 지원.
default는 false이며, 4.0부터는 default가 true.
AndroidManifest.xml에서 android:hardwareAccelrated를 true로 설정
3. 렌더링 우선 순위 높이기
강제적으로 렌더링 기능에 대한 우선 순위를 높이는 방법이다.
webView.getSettings().setRenderPriority(RenderPriority.HIGH)로 설정
API Level 18부터는 deprecated.
Android - 효율적인 코드 작성하기2
1. Constants 를 final로 선언하라
컴파일러는 <clinit>라고 불리는 class initializer method 생성하며 이는 클래스가 처음 생성될 때 실행된다.
final로 설정되지 않은 값들은 reference될 때 field lookup을 사용해서 접근하여 속도가 조금 느린 편이다.
그러나 final로 설정하면 field lookup을 거치지 않고 바로 사용할 수 있어 빠른 편이다.
class와 function도 final로 설정함으로서 약간의 성능 향상을 노릴 수 있다.
2. Enhanced For Loop 문법을 주의하여 사용
반복문을 여러 번 사용할 경우에는 특히 object 생성에 주의해야 한다.
횟수가 기하학적으로 증가할 수 있고, 발견이 어려울 수 있기 때문이다.
3. Enums를 피하라
Enums의 접속 속도가 느리기 때문에 자주 사용하면 성능이 저하될 수 있다.
따라서 Enums를 지속적으로 사용하는 경우에는 local변수로 만들어 사용하는 것이 좋다.
4. 부동소수점(float)을 가능한 피하라
5. 곱셈 연산을 사용하라.
나누기 연산보다는 곱셈 연산을 사용하는 것이 성능에 더 좋다.
컴파일러는 <clinit>라고 불리는 class initializer method 생성하며 이는 클래스가 처음 생성될 때 실행된다.
final로 설정되지 않은 값들은 reference될 때 field lookup을 사용해서 접근하여 속도가 조금 느린 편이다.
그러나 final로 설정하면 field lookup을 거치지 않고 바로 사용할 수 있어 빠른 편이다.
class와 function도 final로 설정함으로서 약간의 성능 향상을 노릴 수 있다.
2. Enhanced For Loop 문법을 주의하여 사용
반복문을 여러 번 사용할 경우에는 특히 object 생성에 주의해야 한다.
횟수가 기하학적으로 증가할 수 있고, 발견이 어려울 수 있기 때문이다.
3. Enums를 피하라
Enums의 접속 속도가 느리기 때문에 자주 사용하면 성능이 저하될 수 있다.
따라서 Enums를 지속적으로 사용하는 경우에는 local변수로 만들어 사용하는 것이 좋다.
4. 부동소수점(float)을 가능한 피하라
5. 곱셈 연산을 사용하라.
나누기 연산보다는 곱셈 연산을 사용하는 것이 성능에 더 좋다.
Android - 효율적인 코드 작성하기1
1. 오브젝트 생성을 피하라
오브젝트 생성은 메모리를 할당하는 작업으로, 일반 작업에 비해 load가 큰 편.
Java의 GC는 매우 큰 작업으로 구분되는데, 쓸데없는 메모리 할당으로 GC를 초래하게 되면 성능저하를 유발.
반복문에서의 오브젝트 생성은 오버헤드가 크므로 피함.
2. Native Method를 사용하라.
Native Method들은 C/C++ 등으로 구현되어 있어 Java 코드보다 약 10~100배 빨리 실행된다.
따라서 Native Method들을 이용하여 구현하는 것이 성능에 좋다.
3. 내부적인 getters/setters를 피하라
일반적인 OOP개념의 getter/setter는 합리적이나 클래스 내부에서의 변수 접근에도 getter/setter를 사용하는 것은 비효율적이다.
4. Cache Field Loop ups
맴버변수에 접근하는 것은 지역 변수에 접근하는 것보다 훨씬 속도가 느리다.
따라서 맴버변수를 여러 번 사용하는 함수에서는 맴버변수를 지역변수에 할당하여 처리하는 것이 효율적이다.
오브젝트 생성은 메모리를 할당하는 작업으로, 일반 작업에 비해 load가 큰 편.
Java의 GC는 매우 큰 작업으로 구분되는데, 쓸데없는 메모리 할당으로 GC를 초래하게 되면 성능저하를 유발.
반복문에서의 오브젝트 생성은 오버헤드가 크므로 피함.
2. Native Method를 사용하라.
Native Method들은 C/C++ 등으로 구현되어 있어 Java 코드보다 약 10~100배 빨리 실행된다.
따라서 Native Method들을 이용하여 구현하는 것이 성능에 좋다.
3. 내부적인 getters/setters를 피하라
일반적인 OOP개념의 getter/setter는 합리적이나 클래스 내부에서의 변수 접근에도 getter/setter를 사용하는 것은 비효율적이다.
4. Cache Field Loop ups
맴버변수에 접근하는 것은 지역 변수에 접근하는 것보다 훨씬 속도가 느리다.
따라서 맴버변수를 여러 번 사용하는 함수에서는 맴버변수를 지역변수에 할당하여 처리하는 것이 효율적이다.
JavaScript - 성능 향상 (오브젝트)
* 오브젝트 생성
객체를 생성하는 방법으로 리터럴을 사용하는 방법과 생성자를 사용하는 방법이 있음
var obj = {}; // 리터럴
var obj = new Object(); // 생성자
큰 차이는 없으나 리터럴을 사용하는 방법이 조금 더 나은 성능을 보임
* 오브젝트 초기화
객체를 초기화하는 방법으로 .연산자를 사용하는 방법과 []연산자를 사용하는 방법이 있음.
obj.a = 1; // .연산자
obj["a"] = 1; // []연산자
사파리를 제외한 대부분의 브라우저에서 비슷한 성능을 보임. 사파리는 .연산자를 사용하는 방법이 더 좋은 성능을보임.
* 코드 최적화
어느 방법을 사용하더라도 비슷한 성능을 보임
객체를 생성하는 방법으로 리터럴을 사용하는 방법과 생성자를 사용하는 방법이 있음
var obj = {}; // 리터럴
var obj = new Object(); // 생성자
큰 차이는 없으나 리터럴을 사용하는 방법이 조금 더 나은 성능을 보임
* 오브젝트 초기화
객체를 초기화하는 방법으로 .연산자를 사용하는 방법과 []연산자를 사용하는 방법이 있음.
obj.a = 1; // .연산자
obj["a"] = 1; // []연산자
사파리를 제외한 대부분의 브라우저에서 비슷한 성능을 보임. 사파리는 .연산자를 사용하는 방법이 더 좋은 성능을보임.
* 코드 최적화
어느 방법을 사용하더라도 비슷한 성능을 보임
JavaScript - 성능 향상 (배열)
* 배열 생성, 초기화
배열은 생성자 혹은 리터럴 형식을 사용해 객체를 생성할 수 있다.
var arr = new Array(); // 생성자
var arr = []; // 리터럴 형식
리터럴 형식을 사용한 경우 여러 브라우저에서 좀 더 좋은 성능을 보임.
* 배열 데이터 할당
배열에 데이터를 할당하는 방법에는 접근자 []를 사용하는 방법과 push() 메소드를 사용하는 방법이 있다.
arr[i] = 10; // 접근자
arr.push(10); // push 메소드
크롬을 제외한 대부분의 브라우저에서 접근자를 사용한 경우 좀 더 좋은 성능을 보임.
* 코드 최적화
배열 생성시 리터럴 형식을 사용하고, 접근자[]를 사용하여 데이터를 할당하는 것이 최적화된 방법으로 보임
배열은 생성자 혹은 리터럴 형식을 사용해 객체를 생성할 수 있다.
var arr = new Array(); // 생성자
var arr = []; // 리터럴 형식
리터럴 형식을 사용한 경우 여러 브라우저에서 좀 더 좋은 성능을 보임.
* 배열 데이터 할당
배열에 데이터를 할당하는 방법에는 접근자 []를 사용하는 방법과 push() 메소드를 사용하는 방법이 있다.
arr[i] = 10; // 접근자
arr.push(10); // push 메소드
크롬을 제외한 대부분의 브라우저에서 접근자를 사용한 경우 좀 더 좋은 성능을 보임.
* 코드 최적화
배열 생성시 리터럴 형식을 사용하고, 접근자[]를 사용하여 데이터를 할당하는 것이 최적화된 방법으로 보임
MySql - 테이블 스캔 피하기
* EXPLAIN을 실행하면 MySQL이 쿼리를 해석하기 위해 테이블을 스캔할 때 type 컬럼에 ALL을 보여줌.
이것은 일반적으로 아래 조건 아래에서 발생.
- 테이블이 너무 작아서 키 룩업 (lookup)을 실행하는 것보다 테이블 스캔을 하는 것이 더 빠름. 일반적으로 10개 미만의 짧은 길이의 행을 가진 테이블이 여기에 해당.
- 인덱스된 컬럼에 대해서 사용할 수 있는 제약 사항이 ON 또는 WHERE 구문에 존재하지 않음.
- 인덱스된 컬럼을 상수 값과 비교할 수 있고, MySQL이 테이블 대부분을 커버하고 있는 상수를 계산해서 테이블 스캔이 빠르게 진행되도록 만드는 경우.
- 다른 컬럼을 통해서 낮은 기수 (cardinality)를 가지고 있는 (많은 열이 키 값과 매치가 됨) 행을 사용할 수 있는 경우, MySQL은 많은 키 룩업 (lookup)이 진행이 되고 이에 따라서 테이블 스캔이 보다 빠를 것이라고 가정.
* 작은 테이블의 경우에는 테이블 스캔이 적절할 수도 있을 것이나 대형 테이블의 경우 옵티마이저가 올바르지 않은 테이블 스캔을 선택하지 못하도록 하기 위해서 아래 기법을 사용.
- 스캔이 된 테이블에 대한 키 배포 업데이트 작업은 ANALYZE TABLE tbl_name를 사용.
- 주어진 인덱스를 사용하는 것 보다 테이블 스캔을 하는 것이 보다 비효율적이라고 MySQL에게 지시하기 위해서, 스캔이 된 테이블에 대해서 FORCE INDEX를 사용.
SELECT * FROM t1, t2 FORCE INDEX (index_for_column)
WHERE t1.col_name=t2.col_name;
- 어떠한 키 스캔도 1,000개 이상의 키 검색이 발생하지 않는다고 가정하게끔 옵티마이저를 만들기 위해서, mysqld를 --max-seeks-for-key=1000 옵션과 함께 시작하거나 또는 SET max_seeks_for_key=1000를 사용.
이것은 일반적으로 아래 조건 아래에서 발생.
- 테이블이 너무 작아서 키 룩업 (lookup)을 실행하는 것보다 테이블 스캔을 하는 것이 더 빠름. 일반적으로 10개 미만의 짧은 길이의 행을 가진 테이블이 여기에 해당.
- 인덱스된 컬럼에 대해서 사용할 수 있는 제약 사항이 ON 또는 WHERE 구문에 존재하지 않음.
- 인덱스된 컬럼을 상수 값과 비교할 수 있고, MySQL이 테이블 대부분을 커버하고 있는 상수를 계산해서 테이블 스캔이 빠르게 진행되도록 만드는 경우.
- 다른 컬럼을 통해서 낮은 기수 (cardinality)를 가지고 있는 (많은 열이 키 값과 매치가 됨) 행을 사용할 수 있는 경우, MySQL은 많은 키 룩업 (lookup)이 진행이 되고 이에 따라서 테이블 스캔이 보다 빠를 것이라고 가정.
* 작은 테이블의 경우에는 테이블 스캔이 적절할 수도 있을 것이나 대형 테이블의 경우 옵티마이저가 올바르지 않은 테이블 스캔을 선택하지 못하도록 하기 위해서 아래 기법을 사용.
- 스캔이 된 테이블에 대한 키 배포 업데이트 작업은 ANALYZE TABLE tbl_name를 사용.
- 주어진 인덱스를 사용하는 것 보다 테이블 스캔을 하는 것이 보다 비효율적이라고 MySQL에게 지시하기 위해서, 스캔이 된 테이블에 대해서 FORCE INDEX를 사용.
SELECT * FROM t1, t2 FORCE INDEX (index_for_column)
WHERE t1.col_name=t2.col_name;
- 어떠한 키 스캔도 1,000개 이상의 키 검색이 발생하지 않는다고 가정하게끔 옵티마이저를 만들기 위해서, mysqld를 --max-seeks-for-key=1000 옵션과 함께 시작하거나 또는 SET max_seeks_for_key=1000를 사용.
Java - 성능 향상 (프로그래밍)
* 자바에 적합한 프로그래밍 방법을 사용하여 성능 향상 효과를 얻을 수 있음.
* final 사용
final 클래스는 컴파일러에 의해 하위 클래스에 의해서 오버라이딩이 불가능한 클래스로 인식되어 컴파일시 동적 메소드 호출 기능을 제거하여 메소드 호출을 최적화. 따라서 일반 메소드 호출보다 훨씬 빠름.
클래스 전체를 final로 사용하는 것은 문제가 발생할 가능성이 많으므로 꼭 필요한 경우가 아니라면 피하는 것이 좋음.
메소드 단위로 final을 사용하는 것이 효율적.
* String 대신 StringBuffer 사용
String은 자바가상머신에 의해 StringBuffer 로 변환되어 처리됨.
String 결합(concat) 연산은 내부적으로 StringBuffer로 변환되어 결합 후 다시 String으로 변환되기에 많은 자원이 소모됨.
따라서 String보다는 StringBuffer 혹은 char 배열을 사용하는 것이 빠름.
* 임시 객체 생성 자제
반복문이나 자주 사용하는 메소드 내에서 생성하는 임시 객체들은 가비지 컬렉터에게 부하를 줌.
따라서 반복문이나 자주 사용하는 메소드 내에서 임시 객체 생성을 피하는 것이 좋음.
* final 사용
final 클래스는 컴파일러에 의해 하위 클래스에 의해서 오버라이딩이 불가능한 클래스로 인식되어 컴파일시 동적 메소드 호출 기능을 제거하여 메소드 호출을 최적화. 따라서 일반 메소드 호출보다 훨씬 빠름.
클래스 전체를 final로 사용하는 것은 문제가 발생할 가능성이 많으므로 꼭 필요한 경우가 아니라면 피하는 것이 좋음.
메소드 단위로 final을 사용하는 것이 효율적.
* String 대신 StringBuffer 사용
String은 자바가상머신에 의해 StringBuffer 로 변환되어 처리됨.
String 결합(concat) 연산은 내부적으로 StringBuffer로 변환되어 결합 후 다시 String으로 변환되기에 많은 자원이 소모됨.
따라서 String보다는 StringBuffer 혹은 char 배열을 사용하는 것이 빠름.
* 임시 객체 생성 자제
반복문이나 자주 사용하는 메소드 내에서 생성하는 임시 객체들은 가비지 컬렉터에게 부하를 줌.
따라서 반복문이나 자주 사용하는 메소드 내에서 임시 객체 생성을 피하는 것이 좋음.
Java - 성능 저하 원인
* 멀티스레드, 가비지컬렉션, 런타임 바인딩 등은 자바에서 제공하는 편리한 기능이나 프로그램 실행 속도를 느리게하는 원인이 된다. 이러한 기능을 지원하기 위해 보다 많은 자원과 계산이 필요하기 때문.
* 동적 바인딩 / 동적 클래스 로딩
자바는 런타임시 필요한 클래스들을 바인딩. C는 컴파일시 처리. 상대적으로 자바가 함수 호출이 느림.
동적 클래스 로딩은 실행중에 자바 가상 머신에 의해 안전한지 검사하고 초기화하기 때문에 성능 저하를 유발.
* 가비지 컬렉션
사용되지 않는 객체의 메모리를 자동으로 가용 자원으로 돌려주는 유용한 기능이나, 백그라운드에서 스레드로 수행되어야 하기 때문에 성능 저하를 유발.
* 멀티스레드
멀티스레드 사용에 있어 중요한 부분이 스레드간 충돌을 방지하고, 공유 자원에 대한 일관성을 유지하는 것으로 이를 동기화라고 한다.
동기화를 위해 synchronized 키워드를 사용하는데, 스레드 모니터에서는 모든 스레드를 관리하며 synchronized 설정된 스레드가 한 순간에 한 번만 사용되도록 해야한다.
JDK에서 제공되는 많은 메소드들이 synchronized 선언되어 있으며, 백그라운드에서 스레드모니터가 항상 스레드 관리 작업을 수행하는데 많은 자원이 소모되어 성능 저하를 유발
* 동적 바인딩 / 동적 클래스 로딩
자바는 런타임시 필요한 클래스들을 바인딩. C는 컴파일시 처리. 상대적으로 자바가 함수 호출이 느림.
동적 클래스 로딩은 실행중에 자바 가상 머신에 의해 안전한지 검사하고 초기화하기 때문에 성능 저하를 유발.
* 가비지 컬렉션
사용되지 않는 객체의 메모리를 자동으로 가용 자원으로 돌려주는 유용한 기능이나, 백그라운드에서 스레드로 수행되어야 하기 때문에 성능 저하를 유발.
* 멀티스레드
멀티스레드 사용에 있어 중요한 부분이 스레드간 충돌을 방지하고, 공유 자원에 대한 일관성을 유지하는 것으로 이를 동기화라고 한다.
동기화를 위해 synchronized 키워드를 사용하는데, 스레드 모니터에서는 모든 스레드를 관리하며 synchronized 설정된 스레드가 한 순간에 한 번만 사용되도록 해야한다.
JDK에서 제공되는 많은 메소드들이 synchronized 선언되어 있으며, 백그라운드에서 스레드모니터가 항상 스레드 관리 작업을 수행하는데 많은 자원이 소모되어 성능 저하를 유발
JavaScript - 성능 향상 (반복문)
* for-in
반복문 중 가장 느리므로 사용하지 말 것.
for-in외의 반복문은 주어진 배열 객체를 배열의 특성에 맞게 순차적으로 모든 요소를 탐색.
for-in구문은 배열을 배열이 아닌 일반 객체로 취급, 반복 시점마다 객체의 모든 속성을 무작위로 탐색.
* Array.length
반복문 안에서 직접 사용하지 말 것. 변수 선언 후 사용하는 것이 더 빠름.
반복문 안에서 length를 구하게되면 반복횟수만큼 length를 구하는 작업을 반복.
사용예)
var arr = [1, 2, 3];
for (var i=0; i<arr.length; i++) {
// ...
}
==>
var len = arr.length;
for (var i=0; i<len; i++) {
// ...
}
반복문 중 가장 느리므로 사용하지 말 것.
for-in외의 반복문은 주어진 배열 객체를 배열의 특성에 맞게 순차적으로 모든 요소를 탐색.
for-in구문은 배열을 배열이 아닌 일반 객체로 취급, 반복 시점마다 객체의 모든 속성을 무작위로 탐색.
* Array.length
반복문 안에서 직접 사용하지 말 것. 변수 선언 후 사용하는 것이 더 빠름.
반복문 안에서 length를 구하게되면 반복횟수만큼 length를 구하는 작업을 반복.
사용예)
var arr = [1, 2, 3];
for (var i=0; i<arr.length; i++) {
// ...
}
==>
var len = arr.length;
for (var i=0; i<len; i++) {
// ...
}
JavaScript - 성능 향상 (스코프 체인 탐색 줄이기)
* 스코프 체인
탐색 성능을 높이는 것이 본질.
자바스크립트 실행성능 저하는 변수, 객체, 함수의 메모리상 위치 탐색 작업.
* 스코프 체인 구성
활성화 객체(Activate Object) + 전역 객체(Global Object)
* 활성화 객체
함수 내부 접근시 생성. (지역변수, this, arguments 객체)
함수 빠져 나오면 활성화 객체 제거됨 .
* 실행 문맥 (Execution Context) > 스코프 체인 (1, 2) > 활성화 객체 (1) > 전역 객체 (2) 순으로 실행.
* 함수가 전역 속성 참조 순서
실행문맥 > 스코프 체인 > 활성화 객체 (함수) > 스코프 체인 > 전역 객체 순으로 속성 참조
* 활성화 객체에서 전역 변수 사용시
함수 내부에 var LocalVariable = GlobalVariable; 식으로 지역변수화하여 전역속성 탐색을 제거.
탐색 성능을 높이는 것이 본질.
자바스크립트 실행성능 저하는 변수, 객체, 함수의 메모리상 위치 탐색 작업.
* 스코프 체인 구성
활성화 객체(Activate Object) + 전역 객체(Global Object)
* 활성화 객체
함수 내부 접근시 생성. (지역변수, this, arguments 객체)
함수 빠져 나오면 활성화 객체 제거됨 .
* 실행 문맥 (Execution Context) > 스코프 체인 (1, 2) > 활성화 객체 (1) > 전역 객체 (2) 순으로 실행.
* 함수가 전역 속성 참조 순서
실행문맥 > 스코프 체인 > 활성화 객체 (함수) > 스코프 체인 > 전역 객체 순으로 속성 참조
* 활성화 객체에서 전역 변수 사용시
함수 내부에 var LocalVariable = GlobalVariable; 식으로 지역변수화하여 전역속성 탐색을 제거.
JavaScript - 성능 향상 (성능우위 문법)
* 배열 생성
var arr = new Array(); 대신 var arr = []; 사용
* 배열 접근
arr.push(i) 대신 arr[i] = value 사용
* 객체 생성
var obj = new Object(); 대신 var obj = {}; 사용
* 객체 접근
obj["a"] = 1 대신 obj.a = 1; 사용
* 문자열 생성
var str = new String("aaa"); 대신 var str = "aaa"; 사용
* 문자열 연산
loop문에서 문자열 조작시 str += "test"; 대신 arr=[]; loop{ arr[i]="test"; } arr.join(""); 사용
String과 StringBuffer개념과 유사
* 정규표현식
탐색 대상을 축소.
loop 문 안에 정규표현식을 넣지 말고 밖에 놓아 한번만 컴파일되도록 처리.
(loop문에 있으면 계속 컴파일됨)
var arr = new Array(); 대신 var arr = []; 사용
* 배열 접근
arr.push(i) 대신 arr[i] = value 사용
* 객체 생성
var obj = new Object(); 대신 var obj = {}; 사용
* 객체 접근
obj["a"] = 1 대신 obj.a = 1; 사용
* 문자열 생성
var str = new String("aaa"); 대신 var str = "aaa"; 사용
* 문자열 연산
loop문에서 문자열 조작시 str += "test"; 대신 arr=[]; loop{ arr[i]="test"; } arr.join(""); 사용
String과 StringBuffer개념과 유사
* 정규표현식
탐색 대상을 축소.
loop 문 안에 정규표현식을 넣지 말고 밖에 놓아 한번만 컴파일되도록 처리.
(loop문에 있으면 계속 컴파일됨)
MySql - 성능 최적화 (글로벌 변수)
* innodb_buffer_pool_size, innodb_log_file_size, innodb_log_files_in_group,
innodb_flush_log_at_trx_commit, innodb_doublewrite, sync_binlog
정도가 성능에 직접적인 영향을 미침.
* innodb_buffer_pool_size
InnoDB에게 할당하는 버퍼 사이즈로 50~60%가 적당.
지나치게 많이 할당하면 Swap이 발생할 수 있음.
* innodb_log_file_size
트랜잭션 로그를 기록하는 파일 사이즈이며, 128MB ~ 256MB가 적당.
* innodb_log_files_in_group
트랜잭션 로그 파일 개수로 3개로 설정.
* innodb_flush_log_at_trx_commit
일반적으로 2로 설정.
0 : 초당 1회씩 트랜잭션 로그 파일(innodb_log_file)에 기록
1 : 트랜잭션 커밋 시 로그 파일과 데이터 파일에 기록
2 : 트랜잭션 커밋 시 로그 파일에만 기록, 매초 데이터 파일에 기록
* innodb_doublewrite
이중으로 쓰기 버퍼를 사용하는지 여부를 설정하는 변수.
활성화 시 innodb_doublewrite 공간에 기록 후 데이터 저장.
활성 권장.
* sync_binlog
트랜잭션 commit시 바이너리 로그에 기록할 것인지에 관한 설정.
비활성 권장
innodb_flush_log_at_trx_commit, innodb_doublewrite, sync_binlog
정도가 성능에 직접적인 영향을 미침.
* innodb_buffer_pool_size
InnoDB에게 할당하는 버퍼 사이즈로 50~60%가 적당.
지나치게 많이 할당하면 Swap이 발생할 수 있음.
* innodb_log_file_size
트랜잭션 로그를 기록하는 파일 사이즈이며, 128MB ~ 256MB가 적당.
* innodb_log_files_in_group
트랜잭션 로그 파일 개수로 3개로 설정.
* innodb_flush_log_at_trx_commit
일반적으로 2로 설정.
0 : 초당 1회씩 트랜잭션 로그 파일(innodb_log_file)에 기록
1 : 트랜잭션 커밋 시 로그 파일과 데이터 파일에 기록
2 : 트랜잭션 커밋 시 로그 파일에만 기록, 매초 데이터 파일에 기록
* innodb_doublewrite
이중으로 쓰기 버퍼를 사용하는지 여부를 설정하는 변수.
활성화 시 innodb_doublewrite 공간에 기록 후 데이터 저장.
활성 권장.
* sync_binlog
트랜잭션 commit시 바이너리 로그에 기록할 것인지에 관한 설정.
비활성 권장
피드 구독하기:
글 (Atom)