Optimizing V8 memory consumption · V8
Show navigation Memory consumption is an important dimension in the JavaScript virtual machine performance trade-off space. Over the last few months the V8 team analyzed and significantly reduced the memory footprint of several websites that were identified as representative of modern web development patterns. In this blog post we present the workloads and tools we used in our analysis, outline me
Optimization killers
Introduction This document will contain advice to avoid writing code that will perform significantly worse than expected. Specifically those patterns that cause V8 (relevant to Node.JS, Opera, Chromium...) to refuse to optimize the affected function. vhf is also working on a similar project that tries to list every killers in V8 Crankshaft Engine: V8 Bailout Reasons. Some V8 background In V8 there
v8-perf
v8-perf Notes and resources related to v8 and thus Node.js performance. data types v8 compiler v8 garbage collector memory profiling performance profiling runtime functions v8 source and documentation It's best to dig into the source to confirm assumptions about v8 performance first hand. source home of v8 source code v8 code search v8 source code mirror on github documentation Documentation for s
String.prototype.normalizeが実装された - JS.next
実装されたメソッド String.prototype.normalize(form = "NFC") form（初期値："NFC"）の形式で正規化した文字列を返す 詳細 複雑な文字は、一文字に見えても、文字コード上は複数の構成文字から成り立っている場合がある。 例えば、『が』(濁点付き平仮名か)と、『か』(平仮名か) ＋『゛[U+3099]』(合成用濁点)は、 同じ意味を持ち同じように見えるが、文字コードが異なるためそのままではプログラム上では異なる文字列として扱われてしまう。 ga_NFC = 'が' // 'が' ga_NFD = 'か\u3099' // 'が' escape(ga_NFC) // '%u304C' escape(ga_NFD) // '%u304B%u3099' ga_NFC.length // 1 ga_NFD.length // 2 ga_NFC == ga_
Promiseについて - JS.next
概要 Promiseとは非同期処理を上手く扱う為のAPIであり、パターンである。 非同期の処理の完了後に続けて処理を行いたいとき、よくコールバックパターンが使われるが、処理が連続するとコールバック地獄と言われる分かりづらいソースコードになってしまう。 また、複数の非同期処理が完了した時に処理を行うなど、コールバックパターンでは難しい事をスマートにできるのがこのPromiseである。 今まではDOMの方でDOM Promiseとして仕様策定が進められていたり、ライブラリのDeferredが有名だったが、ES2015標準に入ることになり、V8に実装された。 実装されたメソッド Promise.resolve(x) Promise.reject(x) Promise.all( [p1, p2, p3, ......] ) Promise.race( [p1, p2, p3, ......] )
Effectively managing memory at Gmail scale | Articles | web.dev
Effectively managing memory at Gmail scale Stay organized with collections Save and categorize content based on your preferences. Introduction While JavaScript employs garbage collection for automatic memory management, it is not a substitute for effective memory management in applications. JavaScript applications suffer from the same memory related problems that native applications do, such as me
Google Chromeに入ったジェネレータとPromiseで非同期処理に革命が起きた - 素人がプログラミングを勉強していたブログ
Google Chrome Canary（正確にはV8）に、ついにGenerators（yield）が入った。これを上手に使うと、エラー処理を含む非同期コードを同期的に書くことができるようになり、見通しが極めて良くなるので、ここで紹介する。 ここで紹介するものはいずれNode.jsでも使用できるようになるので、Webとの互換性を気にする必要のないNode.jsでは近いうちに活用できるようになると思う。 下のコードを動かすためには、最新のGoogle Chrome Canaryで、chrome://flagsからexperimental javascriptを有効にしておく必要がある。 ES6 HarmonyのGenerator構文について functionではなくfunction*というキーワードを使うと、yieldキーワードが使えるようになる。 function* range(begin
JavaScript(V8)で避けるべき(だった?)クロージャの使い方 - kazuhoのメモ置き場
Grokking V8 closures for fun (and profit?) に、ほんの少しだけ触れられている話なんですが。 ごく最近まで V8 には、オブジェクトリテラルの中で関数リテラルを使った場合に非常に遅くなる(というかGCが多発する)問題があった。 たとえば、 function doit() { for (var i = 0; i < 1000; ++i) { for (var j = 0; j < 1000; ++j) { var o = { f: function () { return i + j; } }; } } } doit(); というコードを node-0.6.19 で実行すると、以下のように mark-sweep GC が大量に発生して処理に時間がかかっていることが分かる。 $ time /usr/local/node-0.6.19/bin/node -
http://www12.ocn.ne.jp/~yamazaki/v8.txt
V8 JavaScript Engineのコンパイラのソースの簡単なメモ 特徴 ・バイトコードインタープリタは無く，コンパイル実行しかない． JITではなく，完全コンパイル方式． 今はIA32とARMの2種類のみサポート．以下は，ia32のみチェックする． たぶん，スタックモデルなので，他のCPUのコンパイラを作るのは，それほど大変ではない． ・evalがある． ・世代別GCが入っているらしい．spaces.hの36行目から詳細な記述．コメント によく出てくる「remembered set bits」は，old領域を管理するビットテー ブル(?)のことらしい．ポインタにGC bitを埋め込んだりはしていない．た ぶん．ただ，下のSmiのところにあるように，下位2ビットには意味がある． ・Inline cache をやっている．たぶん，見つかったメソッドのキャッシング． ・コンパイル自身は，
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Using Eclipse as Node Applications Debugger