bytearray - binary 처리 benchmark

[Jaeho Lee]

실험 대상 : 4MB 짜리 바이너리 x 6

실험 결과 : 4MBx6개의 바이너리를 합산했을 때 걸리는 시간 측정. 시간 단위는 ms.

1번타자 : MacBook AIR - Flash Emulator

BUFFER LENGTH: 1048576/4194304

2 buffer : Loading Time >> 470 (단순 데이터 적재:AS3 ByteArray)

CModule loading Time: 89 (ByteArray 2개를 C타입으로 변환)

Result : 1.25

summing time : 20 (2track 합산)

total length: 1048576

Final Answer: 1.25

Final Answer: 2097151.25

ByteArray Final : 1.25

ByteArray Final : 2097151.25

time elapsed : 1 (C타입을 ByteArray로 전환)

-------- top line ----------

stack 6tracks elapsed time : 19 (기존 4MB ByteArray를 C타입으로 변환)

6track summing time : 124 (6개의 C Buffer를 합산)

Final Answer: 3.75

Final Answer: 6291454

ByteArray Final : 4.0267712670837943e-41

ByteArray Final : -1.06233240163576e+37

time elapsed : 1 (C타입을 ByteArray로 전환 - 의미없을 정도로 짧음)

2번타자: Xperia Ray (Debug mode)

[trace] BUFFER LENGTH: 1048576/4194304

[trace] 2 buffer : Loading Time >> 3559

[trace] CModule loading Time: 1650

[trace] Result : 1.25

[trace] summing time : 276

[trace] total length: 1048576

[trace] Final Answer: 1.25

[trace] Final Answer: 2097151.25

[trace] ByteArray Final : 1.25

[trace] ByteArray Final : 2097151.25

[trace] time elapsed : 7

[trace] -------- top line ----------

[trace] stack 6tracks elapsed time : 1632

[trace] 6track summing time : 1782

[trace] Final Answer: 3.75

[trace] Final Answer: 6291454

[trace] ByteArray Final : 4.0267712670837943e-41

[trace] ByteArray Final : -1.06233240163576e+37

[trace] time elapsed : 7

가장 오랜 시간이 걸리는 것은 단순 Data 적재.

실제 6track을 summing 하는 시간은 0.124초/1.6초로 매우 짧음.

대략 AIR vs Ray 속도를 10배로 잡으면 됨.

[Jaeho Lee]

추가 실험. 6track 풀로딩 후 mixdown 테스트.

extract Sound

extract Sound Done: 2757 (mp3 -> byteArray decoding)

convert C Binary

convert C Binary Done: 241 (byteArray -> C binary convert)

mixdownTrack length : 22229672

6track summing time : 495 (6track Summing)

AIR 기준이지만 6track을 단순히 decoding 하는데 매우 시간이 오래걸림 (2.7초)

mixdownTrack 용량이 22MB???

summing 자체는 1초도 안걸림.

android 기준으로 다시 test 해봄.

[trace] extract Sound

[trace] extract Sound Done: 19750

[trace] convert C Binary ---- (CRASH)

예상대로 mp3 추출만 20초 소모.

22MBx6 = 138MB 소모하면서 메모리 부족으로 다운되었을 것으로 예상

Ray 에서 summing은 5초 내외로 예상함.

2013년 7월 2일 화요일 오전 2시 46분 16초 UTC+9, Jaeho Lee 님의 말:

[Junho Youn]

이제 길이 보이는 거 같네요.

아 혹시 decoding도 C에서 할 수 있나요?

2013. 7. 2. 오전 3:10 Jaeho Lee <jh...@appsoulute.com> 작성:

--
You received this message because you are subscribed to the Google Groups "appsoulute" group.
To unsubscribe from this group and stop receiving emails from it, send an email to appsoulute+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jaeho Lee]

http://blog.bjrn.se/2008/10/lets-build-mp3-decoder.html

이런게 있는 걸로 보아 가능하겠죠?

라이브러리 의존성이나 빌드 만들기라는 과제가 생기겠지만 mp3 인/디코딩도 기존 adobe에서 제공하는 것보다 분명 낫겠죠.

2013년 7월 2일 화요일 오전 8시 30분 23초 UTC+9, 윤 준호 님의 말:

[Jaeho Lee]

iPhone Simulator 기준으로 테스트

[trace] 5.91Mb

[trace] extract Sound

[trace] 0:2778709

[trace] 1:2778709

[trace] 2:2778709

[trace] 3:2778709

[trace] 4:2778709

[trace] extract Sound Done: 2155

[trace] convert C Binary

[trace] convert C Binary Done: 4231

[trace] 5.15Mb

[trace] mixdownTrack length : 22229672

[trace] 6track summing time : 56293 (Summing 시간이 56초?!)

[trace] 52.81Mb

장비에서 Summing 시간이 개선된다는 낙관을 하기엔 아직 이른 것으로 보입니다.

일단 Crash 먼저 잡는게 관건이네요.

2013년 7월 2일 화요일 오전 3시 10분 27초 UTC+9, Jaeho Lee 님의 말:

[Jaeho Lee]

Track 갯수를 2개로 줄여서 iPhone 5에서 테스트

[trace] 5.80Mb

[trace] extract Sound

[trace] 0:2778709

[trace] 1:2778709

[trace] extract Sound Done: 3201

[trace] convert C Binary

[trace] convert C Binary Done: 4662

[trace] 5.07Mb

[trace] mixdownTrack length : 22229672

[trace] 6track summing time : 93009

crash는 피했지만 Summing Time은 93초 절망적.

다시 모든 문제는 원점으로 회귀.

다시 4track 으로 테스트

[trace] 5.83Mb

[trace] extract Sound

[trace] 0:2778709

[trace] 1:2778709

[trace] 2:2778709

[trace] 3:2778709

[trace] extract Sound Done: 6014

[trace] convert C Binary

[trace] convert C Binary Done: 9076

[trace] 5.11Mb

[trace] mixdownTrack length : 22229672

<CRASH>

4개의 Track까지 메모리 할당 성공 후. mixdownTrack의 메모리를 할당하다 out.

3개 Track으로 재시도.

[trace] 5.87Mb

[trace] extract Sound

[trace] 0:2778709

[trace] 1:2778709

[trace] 2:2778709

[trace] extract Sound Done: 4178

[trace] convert C Binary

[trace] convert C Binary Done: 7290

[trace] 5.16Mb

[trace] mixdownTrack length : 22229672

[trace] 6track summing time : 106402 (106초)

[trace] 27.88Mb

재생은 됨.

중간 중간 지터 발생이 약간 있음.

곡 길이가 1/2로 줄어들음.

ByteArray 연산에 비해 잇점이 전혀 없는 것으로 확인

부동 소숫점 계산을 하는 부분인 각 트랙 volume에 *.7 곱하는 부분을 제거 후 재실행

[trace] 5.88Mb

[trace] extract Sound

[trace] 0:2778709

[trace] 1:2778709

[trace] 2:2778709

[trace] extract Sound Done: 4143

[trace] convert C Binary

[trace] convert C Binary Done: 6759

[trace] 5.15Mb

[trace] mixdownTrack length : 22229672

[trace] 6track summing time : 95017 (95초. 소폭 개선이지만 의미없는 수치)

결론

1. iOS기준 버퍼에 로딩할 수 있는 용량은 100MB를 넘어버릴 경우 Crash

2. ByteArray 를 Byte 타입으로 변환하여 연산하는 것은 모바일일 경우 이득이 없음. (only Desktop)

3. Flascc는 native를 사용하는 것이 아니라 단지 as3대신 c/c++로 코딩을 할 수 있고 해당 언어의 라이브러리를 사용하는 것이 전부.

4. C/C++ 라이브러리를 사용한다고 해서 모바일 앱의 성능이 개선될 지는 미지수

2013년 7월 5일 금요일 오후 1시 25분 29초 UTC+9, Jaeho Lee 님의 말: