Optimization killersYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
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 -
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
