Webkit 推出 B3 JIT Compiler (Bare Bones Backend)

Webkit 推出了 B3 加快 optimization 的速度,取代原來 LLVM 的工作:「Introducing the B3 JIT Compiler」。

在文章後方 Performance Results 的部份可以看到最主要的差異在啟動時間:

另外也可以看到其他各種 performance benchmark 也幾乎都是小勝 LLVM。

接下來會有 ARM64 與其他平台的計畫:

B3 is not yet complete. We still need to finish porting B3 to ARM64. B3 passes all tests, but we haven’t finished optimizing performance on ARM. Once all platforms that used the FTL switch to B3, we plan to remove LLVM support from the FTL JIT.

減少「註解長度」增加 Node.js 效率...

在「#NodeJS : A quick optimization advice」這邊看到這樣的效能改善方法... 兩段程式碼,只差在註解:

效能差了 50%:

只是因為註解的長度有差,只要用 --max-inlined-source-size 調整就可以避開了:

超苦超無奈:

So when you have a function or callback that’ll be called repeatedly, try to make it under 600 characters (or your tweaked value), you’ll have a quick win !

關於 KeyCDN 的 HLS streaming 最佳化...

KeyCDN 發表了對 HLS streaming 的最佳化:「New feature: Optimized HLS streaming」。

其中這段看起來就很奇怪:

The index file (.m3u8) will not be cached at all. The .ts files will only be cached for 5 minutes. If the origin server sends other Cache Control headers, it will be ignored by the CDN.

也就是這個畫面:

如果你把對 .m3u8 的壓力全部打到後端,那麼就註定不 scale 啊?之前在 EC2 c3.8xlarge 上面用 Wowza 測試,就發現單台最多只能承受 4000 reqs/sec。

比較好的作法應該是 cache 很短的時間 (也許三到五秒),讓 CDN 幫你擋下來,而不是前面打多少 reqs/sec 後面就吃多少...

HTTPS 的進展

Tony Hunt 在「We’re struggling to get traction with SSL because it’s still a “premium service”」這篇文章裡抱怨了目前 web 要朝向 HTTPS only 還很遠,甚至還酸了一下 Let's Encrypt 冨樫問題:

可是東尼... 你的站也沒上 HTTPS 啊 :/

順便整理一下目前 HTTPS 技術發展出來的優點:

現在網站的 best practice 是 HTTPS + HTTP/2,對 SEO 好、速度又快 (這兩個對營收有影響),而另外也可以增加安全性 (對聲譽有幫助)。

增加一行程式碼讓 PHP Composer 效率爆增

可以直接看 GitHub 上的 commit log:「Disable GC when computing deps, refs #3482」。

      */
     public function run()
     {
+        gc_disable();
+
         if ($this->dryRun) {
             $this->verbose = true;
             $this->runScripts = false;

下面變成祭典了 XDDD

然後依照「Avoid generating duplicate conflict rules by naderman · Pull Request #3482 · composer/composer」這邊的測試 (要看下面的討論),設 zend.enable_gc=0 會省的更多,效率用倍數在跳的...

因為 Composer 的效率為人詬病很久了,這次有人暴發出來,會讓一群人投入資源找更多 optimization... XD

Google 對字串處理的最佳化

Google Research 上看到 Google 針對字串處理最佳化問題所發的論文:「Automated Locality Optimization Based on the Reuse Distance of String Operations (PDF)」。

大原則是想辦法善用 L2/L3 cache,這沒什麼特別的,比較有趣的地方是解決方案,除了自動化的方式外,另外還有工具「提醒」撰寫程式的人,另外還有一些數據以及 code name 可以看...

Linux 上的 Firefox 將會跑得更快...

這是之前在 Slashdot 上看到的消息,主要是因為 Linux 上的 Firefox 6 (還很久...) 將能夠使用 GCC -O3 編譯:「Firefox On Linux Gets Faster Builds — To Be Fast As Windows」。

VirtualBox 裡面裝好 Windows 後用 Firefox 4 (把 extensions 都裝上去),居然比 Linux 下 native Firefox 還快,就有種淡淡地哀愁...

繼續等吧...

2010 年的 Web 最佳化統計

在「The State of Web Performance Optimization – 2010」這篇文章裡提到了 2010 年的 Web 最佳化統計資料,由於這是 WebPagetest 的統計資訊,裡面有很多有趣的統計資料...

看起來網頁愈來愈糟糕 XD 像是 Page Size 愈來愈大,Number of Requests 數量變多,Image Compression 的比例反而變少,以及 Combine JS/CSS 的分數愈來愈低,而整體的 Page Load Time 也變高了...

不過也有不少項目是變好了,主要都是對開發沒有增加難度的... 像是 Keep-Alive 設定、Text Compression (GZip) 以及 Cache Static Content 都可以在 server side 設定一次就解決。人果然是懶惰的,會影響到開發的東西果然都沒什麼進展 XD