Hi Felix dan semuanya,
Thread ini makin menarik, berhubung saya selalu nyentuh source code Kettle
hal ini bisa menjadi optimasi di ETL ini.
Untuk yang tertarik melihat source codenya ambil dari SVN atau sourceforge
untuk project Pentaho, dan lihat di penangan nilai dari step-step di Kettle
ada banyak method conversion.
Salah satunya adalah ini :
private synchronized Double convertStringToNumber(String string) throws
KettleValueException
{
if (Const.isEmpty(string)) return null;
string = trim(string); // see if trimming needs to be performed
before conversion
try
{
return new Double(
getDecimalFormat().parse(string).doubleValue() );
}
catch(Exception e)
{
throw new KettleValueException(toString()+" : couldn't convert
String to number ", e);
}
}
Ada yang tertarik untuk optimasi Kettle ? Ini real project loh... dan bukan
sekedar optimasi untuk main2, minor benchmarking yang berpengaruh besar ke
project2 penanganan data besar.
Perhatikan di atas menggunakan synchronized karena Kettle memproses data
secara multi threading, yang mana tau bisa dihilangkan dengan menggunakan
penanganan concurrency baru.
Regards,
Feris
2008/6/4 Felix Halim <[EMAIL PROTECTED]>:
> FYI, untuk nge run code barusan, harus set -Xmx256m otw bakal kena heap
> space exception.
>
> Trus, tentang kenapa Double.valueOf bisa lebih lambat itu mungkin karena
> Double.valueOf lebih flexible:
>
> Double.valueOf bisa terima input dalam berbagai macam format:
>
> System.out.println(Double.valueOf("1e-2"));
> System.out.println(Double.valueOf("1.282e-2"));
> System.out.println(Double.valueOf("38282.11717e-7"));
> System.out.println(Double.valueOf("38282.11717e7"));
>
> System.out.println(Double.valueOf("238476239487623324234234.1231231231243324234234E-19"));
>
> Gak heran jalannya lebih lambat, pasti banyak pengecekan di dalamnya.
>
> Felix Halim
>
> 2008/6/4 Felix Halim <[EMAIL PROTECTED]>:
>
>> Untuk yang lain yang ingin melakukan micro-benchmark, kalau bisa
>> test-casesnya di-random.
>> Jangan hanya menggunakan single value seperti: "-12.3456"
>> Hasilnya akan sangat bias dan tidak akurat.
>>
>> Untuk T.Budi, saya bikinin testcases random nya.
>> Kamu bisa benchmark menggunakan itu, hasilnya harusnya lebih applicable.
>>
>> Dan, berdasarkan pengalaman benchmark sebelumnya (puts vs. println),
>> Jumlah testcasesnya harus cukup besar sehingga runtimenya adalah hitungan
>> DETIK.
>> Kalau masih ukuran milliseconds masih blum bisa dianggap akurat! (masih
>> bias dengan overhead aneh2).
>>
>> Saat ini hasilnya seperti ini:
>>
>> Double.parseDouble = 1.120404 secs
>> Double.valueOf = 1.146029 secs
>> stringToDouble = 0.502698 secs
>> stringToDoubleFH = 0.467788 secs
>>
>> Double.valueOf itu consistently lebih lambat daripada toDouble bikinan
>> sendiri...
>> Entah kenapa itu... ada yang tahu?
>>
>> Kalau menurut saya, mungkin saja ada pengecekan lain yang membuat
>> Double.valueOf lambat.
>> Entah pengecekan lain itu critical atau tidak (demi precision)?
>>
>> Felix Halim
>
>
>
>
--
Thanks & Best Regards,
Feris
PT. Putera Handal Indotama
A Business Intelligence Company
Jl. K.H. Moh Mansyur No. 11 B 8 - 12
Jakarta - Indonesia
Phone : +6221-30119353
Fax : +6221-5513483
Mobile : +628176-474-525
http://business-intelligence.phi-integration.com
http://blog.komputasiawan.com
