>>>>> "VST" == Vehbi Sinan Tunalioglu <[EMAIL PROTECTED]> writes:
[guzel detay silindi]
VST> ... Bu epostadan en son cikartilacak
VST> sonuc, CL ve Edi Weitz'in regex makinesi cl-ppcre'nin
VST> performans olarak kotu oldugudur. Neticede hangi dil
VST> kullanirsak kullanalim, regex nedeniyle bu tur bir sonuc
VST> verecek.
Dogru, Edi'nin kodu bazi zamanlarda perlden cok hizli. Hizlandirma icin
ipuclari da var:
http://www.weitz.de/cl-ppcre/#performance
Belki daha yeni bir perl ve sbcl ile bunu yapmakta fayda var. Ben sifira
yakin regexp kullaniyorum ama tahminim buradaki arkadaslar iyice
alisiktirlar, bir faydasi olabilir.
[...]
VST> Ote yandan bunlar bana Regular Expression ve Turing Machine
VST> arasindaki kullanim farkini merak ettirdi. Computational
VST> complexity acisindan degil tabii ki... Ama az once gordugumuz
VST> gibi, regex yerine, bu tarz bir kod kullaninca (Turing
VST> Machine equivalent sanirim) daha az CPU cycle ve CONS ile
VST> isimizi halledebiliyoruz. Ne dersiniz?
Hmm. Yok. Bunu belki biraz farkli ifade etmek lazim manasinin acik
olmasi icin. Ben anlamadim bu paragrafi mesela.
VST> Ayrica optimizasyon icin CONS sayisi yeter gosterge midir?
Ben yapiyor olsam dev bir dosya ile butun programi test ederek baslardim.
Hiz yeterli degilse profil. En son mikrooptimizasyon. Cons sayisi elbette
bir faktor, genelde az heap kullanan programlar daha hizli oluyor. Ama
ilk etapta ellenecek sey midir bilmiyorum. Duruma bagli. Bir de bazen
lispler yapabilecegi her optimizasyonu yapmiyorlar, manasiz consing oluyor.
O zaman 'yahu ne oluyor' dedirtme sinyali o aslinda (veya dynamic-extent
kullanilabiliyor mu diye bakmak icin uyari).
Kod aciksa gecin buraya bence, topluca elleyelim bakalim ne hale gelecek.
Iyi bir egzersiz olur.
BM
_______________________________________________
cs-lisp mailing list
[email protected]
http://church.cs.bilgi.edu.tr/lcg
http://cs.bilgi.edu.tr/mailman/listinfo/cs-lisp
