>>>>> "BM" == Bulent Murtezaoglu <[EMAIL PROTECTED]> writes:
BM> Hmm, pekiyi. Hiz tatminkar hale geldi mi? Ne sekle girdi o
BM> kod?
Not: konuyu takip etmeyenler icin de en altta iki tane soru var.
Bizim eposta listemizdeki her epostayi bir assoc list haline getirip
bunlari bir listeye atmasi acisindan en son durum su (uzak dosya yerel
klasore indirildikensonra):
1. En basta, her satir uzerinde 5 tane regex calistirdigimizda:
; Evaluation took:
; 48.09 seconds of real time
; 39.092056 seconds of user run time
; 5.539157 seconds of system run time
; 82,059,902,984 CPU cycles
; [Run times include 5.04 seconds GC run time]
; 0 page faults and
; 1,972,233,616 bytes consed.
2. Regexlerin sayisini azalttigimizda:
; Evaluation took:
; 14.26 seconds of real time
; 10.120461 seconds of user run time
; 1.274807 seconds of system run time
; 21,527,674,082 CPU cycles
; [Run times include 1.23 seconds GC run time]
; 0 page faults and
; 406,617,184 bytes consed.
3. Tamamen regexlerden kurtulmus halimiz:
; Evaluation took:
; 2.93 seconds of real time
; 1.975699 seconds of user run time
; 0.06899 seconds of system run time
; 1,550,910,080 CPU cycles
; [Run times include 0.09 seconds GC run time]
; 0 page faults and
; 8,757,184 bytes consed.
Ozellikle tarihi denetleyen fonksiyon:
(defun is-date-line? (line)
(ppcre:scan "^Date:[ ]+[A-Za-z]{3}[ ]+[A-Za-z]{3}[ ]+[0-9]{1,2}[
]+[0-9]{1,2}:[0-9]{1,2}:[0-9]{1,2}[ ]+[0-9]{4}" line))
seklinden:
(defun date-line? (line)
(and (> (length line) 6) (equal (subseq line 0 6) "Date: ")))
sekline cevrildiginde yapilan cons sayisindaki degisiklik de sirasiyla
soyle oldu:
CL-USER> (time (is-date-line? "Date: bla bla bla"))
; Compiling LAMBDA NIL:
; Compiling Top-Level Form:
; Evaluation took:
; 0.07 seconds of real time
; 0.059991 seconds of user run time
; 0.003999 seconds of system run time
; 37,124,783 CPU cycles
; 0 page faults and
; 517,296 bytes consed.
;
NIL
CL-USER> (time (date-line? "Date: bla bla bla"))
; Compiling LAMBDA NIL:
; Compiling Top-Level Form:
; Evaluation took:
; 0.01 seconds of real time
; 0.001 seconds of user run time
; 0.0 seconds of system run time
; 7,164,731 CPU cycles
; 0 page faults and
; 152 bytes consed.
;
T
CL-USER>
Tabii ki ayni isi yapmiyorlar. Ancak, ikincisi benim isimi hayli hayli
gorecek. Kisacasi regex yazmadan once, birkez daha regex kullanmadan
yapmanin mumkun olup olmayacagi ve oldugu takdirde regexden daha
maliyetli olmayacagi konusunda dusunmemiz gerektigine dair bilgim
pekisti. Ozellikle de binlerce (hatta onbinlerce) satir uzerinde
iterate ederken regex kullanmak soz konusu oldugu durumlarda.
Bu durumun pek de common lisp ile alakasi olmadigini
belirtmeliyim. Tamamen yukarida ozetledigim bilgi eksikliginden
kaynaklaniyor. Bu epostadan en son cikartilacak sonuc, CL ve Edi
Weitz'in regex makinesi cl-ppcre'nin performans olarak kotu
oldugudur. Neticede hangi dil kullanirsak kullanalim, regex nedeniyle
bu tur bir sonuc verecek.
Ote yandan bunlar bana Regular Expression ve Turing Machine arasindaki
kullanim farkini merak ettirdi. Computational complexity acisindan
degil tabii ki... Ama az once gordugumuz gibi, regex yerine, bu tarz
bir kod kullaninca (Turing Machine equivalent sanirim) daha az CPU
cycle ve CONS ile isimizi halledebiliyoruz. Ne dersiniz?
Ayrica optimizasyon icin CONS sayisi yeter gosterge midir?
--vst
_______________________________________________
cs-lisp mailing list
[email protected]
http://church.cs.bilgi.edu.tr/lcg
http://cs.bilgi.edu.tr/mailman/listinfo/cs-lisp
