曾經看過Computer Language Benchmarks Game（以前稱爲Great Language Shootout）？在計算機語言基準遊戲中，Perl的chameneos-redux的速度提升
Perl現在有一些非常健康的競爭。我也覺得可能有些地方Perl的分數可以提高。最大的一個是現在在chameneos-redux腳本中— Perl版本在任何語言中運行得最差：比C基線解決方案慢1,626倍！
關於如何製作和優化程序有some restrictions，還有Perl的解釋運行時懲罰，但是1,626次？必須有一些能夠讓程序運行時間減少的東西。
看看source code和the challenge，速度如何提高？
我通過Devel::SmallProf profiler運行source code。配置文件輸出有點過於冗長，不能在這裏發佈，但是您可以使用$ perl -d:SmallProf chameneos.pl 10000自己查看結果（無需爲6000000次會議運行該結果，除非您真的想要！）有關Perl中一些性能分析工具的更多詳細信息，請參見perlperf。原來semaphores是主要的瓶頸。用於檢查信號量是否被鎖定的花費佔總CPU時間的大部分時間。雖然我沒有足夠的時間來查看源代碼使用信號量的原因，但也可能是您可以完全使用信號量。這可能是您改善代碼性能的最佳選擇。
我可以告訴你沒有分析，真的沒有那麼多時間。問題是：該怎麼做。 – 2010-04-10 16:07:54
正如Zaid所說，Thread :: Semaphore相當慢。一種優化可以是對共享變量使用隱式鎖而不是它們。它應該更快，但我懷疑它不會更快。
通常，Perl的線程實現會吸引任何需要大量線程間通信的使用。它非常適合於溝通很少的任務（與CPython的線程和CRuby的線程不同，它們實際上是搶先的）。
有可能改善這種情況，我們需要更好的基元。
我還沒有意識到（C）Ruby到目前爲止還是錯了。 – 2010-04-19 12:20:56
我有一個version基於Jesse Millikian的另一個版本，我認爲它從未發佈過。
我認爲它可能比當前條目運行速度快7倍，並且全部使用標準模塊。我不確定它是否真的符合所有規則。
我試過forks模塊，但我認爲它會減慢它的一點。
這是一個有趣的挑戰，但它不屬於這裏在stackoverflow國際海事組織。 – 2010-04-09 16:39:06
我很好奇你的推理。它似乎與SO有關的所有內容幾乎一致：問題是具體的，它是與編碼有關的，並且有一個可測量的方式來告訴問題是否已被回答。它涉及編程中很難的主題：優化，特別是Perl中的優化。在我的個人代碼中有幾個地方我已經考慮過使用這個基準測試中顯示的線程技術，但在看到結果之後，我非常猶豫。如果有更好的做法，我想知道。如果沒有，那麼我知道要避免它。 – 2010-04-09 17:06:08
它會是一個更好的問題，如果它是「爲什麼Perl線程如此$ $ @＆！* @＃與其他語言相比較慢？」 – mob 2010-04-09 17:20:58