Tag: for

V8 對 for-in 的最佳化

V8 引擎的人對 for-in 的最佳化寫了一篇解釋「Fast For-In in V8」，比較直接的結果就是維基百科與 Facebook 都變快了：

For example, in early 2016 Facebook spent roughly 7% of its total JavaScript time during startup in the implementation of for-in itself. On Wikipedia this number was even higher at around 8%.

可以看得出來是挑比較大的來改，而下一版的 Google Chrome (57) 將會對 for-in 會到另外一個極致：

The most important for-in helpers are at position 5 and 17, accounting for an average of 0.7% percent of the total time spent in scripting on a website. In Chrome 57 ForInEnumerate has dropped to 0.2% of the total time and ForInFilter is below the measuring threshold due to a fast path written in assembler.

主要是因為 spec 對 for-in 的定義寫得很模糊，所以就有很多實作的空間可以調整：

When we look at the spec-text of for-in, it’s written in an unexpectedly fuzzy way,which is observable across different implementations.

Yahoo! 也放出了判斷是否為色情圖片的方案

感覺好像是從 AlphaGo 大勝李世乭開始，透過各類 neural network 的技術就一直冒出來...

Yahoo! 這次放出來判斷是否為色情圖片的也是同源的技術：「Open Sourcing a Deep Learning Solution for Detecting NSFW Images」。

當年沒辦法做的事情，現在的技術已經成熟到被 open source 出來了...

PostgreSQL 9.5 預定提供的 Row Locking 改善

在「More Concurrency: Improved Locking In PostgreSQL」這邊提到 PostgreSQL 的 Row Locking 的改善，也就是 SELECT ... FOR UPDATE 與 SELECT ... FOR SHARE。

查了一下 SELECT 的文件，在 7.2 開始提供 FOR UPDATE (PostgreSQL: Documentation: 7.2: SELECT)，在 8.1 開始提供 FOR SHARE (PostgreSQL: Documentation: 8.1: SELECT)，以維基百科上的紀錄來看，7.2 是 2002 年二月，8.1 是 2005 年十一月，都是已經提很久的功能了。

用 FOR UPDATE 與 FOR SHARE 可以降低對 transaction 的依賴程度，PostgreSQL 的預設值是 READ COMMITTED，配合 Row Locking 就已經可以做到不少效果了，不需要用到 SERIALIZABLE 等級。

而在最新的 PostgreSQL 9.5 (目前還是開發版)，則又多提供了 FOR UPDATE SKIP LOCKED 功能，以官方提供的範例來說，就可以直接避開選位造成的 lock 問題了：

This makes sense because 100 users checking for a free seat concurrently will get 100 different rows. The consequence is that you are not stuck with 1 CPU but you can nicely scale out to all CPUs in the system. As conflicts cannot happen anymore, nobody has to wait on somebody else.

對 locking 控制的更細微。