5倍速いSquirrelFish Extremeの正規表現エンジンWREC
「recursive callを得意とするV8が、recursive callに比重をおいた、V8 Benchmark Suiteで速い!速い!と語られるのはフェアではない」 今回、正規表現のみに焦点を当ててJavaScriptエンジンを比較してみた。 環境 SpiderMonkey - 1.7.0 2007-10-03SFX - Revision: 37445v8 - Revision: 389 SFX(SquirrerlFish Extreme)に新しく搭載されたWREC("the WebKit Regular Expression Compiler")、Safari 3に搭載されているJavaScript Coreに比べて、なんと5倍も速い。正規表現の実行が占める実行時間が、Webアプリケーション全体の実行時間の3%ほどだとすれば、WRECは、2.4%ほどの高速化に貢献している。 V
Drift Diary12: エンジニアからみたChromeの中身
といっても、この内容は、ソースコードをみてるわけでもなく、リリースされてる情報や、Chromeのアプリを触ってみて、実装を推測してみたもので、あくまでも想像です。あしからず。 という、お約束の前置きをしつつ、まず、エンジンについては、リリースではWebKitベースにv8というJavaScriptのエンジンを搭載してると言われてます。UserAgentをみると UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13 ということで、AppleWebKit/525.13ということはSafari3.1ベースのWebKitが採用されてることがわかります。(Safari3.1.1はAppleWe
SlickSpeed Selectors Test
speed/validity selectors test for frameworks. Every framework runs in his own iFrame, thus no conflicts can happen. Tests are run selector by selector, with an interval to prevent the browser from freeezing. Tests are run in a neutral environment, no library or framework is included in the main javascript test, to avoid favoritism. Tests are run against a local copy of this document. beta' src='s
John Resig - JavaScript Performance Rundown
A new JavaScript Engine has hit the pavement running: The new V8 engine (powering the brand-new Google Chrome browser). There are now a ton of JavaScript engines on the market (even when you only look at the ones being actively used in browsers): JavaScriptCore: The engine that powers Safari/WebKit (up until Safari 3.1). SquirrelFish: The engine used by Safari 4.0. Note: The latest WebKit nightly
Benchmark::ProgressBar - D-6 [相変わらず根無し]
Benchmark::ProgressBar Benchmark::ProgressBarというものを書きました。 追記：id:tokuhiromがほぼ同じ物を書いていたんだが、俺がsvk importしたらそのまま上書きしたらしいよ！ 長い時間かかるベンチマークを待つのが苦痛で苦痛でしょうがなかったので、なんとかしてプログレスバーを出したかったのです。 で、元々はこういうコードだったのを use strict; use Benchmark qw(cmpthese); use Crypt::DH; use Crypt::DH::GMP; .... { print "Benchmarking instatiation cost...\n"; cmpthese(500, { pp => sub { Crypt::DH->new(%args) }, gmp => sub { Crypt::DH:
Greenbear Diary - ゲームセンター 終 了 の お 知 ら せ , Google Chromeのチートっぷりをベンチマークで体感してみた
Google Chromeはえええええええｗｗｗｗｗｗｗ なんでこんなに速いの？死ぬの？ あとIE7が6より遅くなっててしょんぼりした。 ベンチマーク環境はこんな感じです。 WinXP CPU Celeron D 2.80GHz メモリ 1024MB ■ [linux][lisp] StumpWMをUbuntuで使ってみた StumpWMはCommon Lispで書かれたタイルベースのウィンドウマネージャだ。操作系統はratpoisonに(つまり、GNU Screenに)似ている。 全てがCLで制御されているため、WMを再起動せずに挙動をハックすることができるのがウリらしい。 とりあえずインストールは sudo aptitude install stumpwm でいけた。 んで、起動する前に sudo vi /usr/share/xsessions/stumpwm.desktop として、
forEach色々とベンチマーク - os0x.blog
cho45さんがCodeReposにあげていたJSEnumeratorに付随していたベンチマークでちょっと遊んでみました。 肝心なことを書き忘れていた。はっきりと差が出ているのは、10回のループをさらに1000回ループさせているからで、大抵の場合はどのメソッドを使っても体感できるほどの差は出ないと思います。 jQuery、prototype.js、MochiKit、fLDR、JSEnumeratorなどで使われているforEach関数の速度比較です。recursive eachは一応オリジナルです。 以下、実験ページ http://ss-o.net/jsenumerator/benchmark/10.html http://ss-o.net/jsenumerator/benchmark/100.html 結果 とりあえずWindowsのみmacは後で面倒だか、じゃなくて、windowsと大
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PRODATA :: Programming