サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
参議院選挙2025
blog.mrale.ph
I have a thing for virtual machines that are implemented in the language (or a subset of the language) they are built to execute. If I were in the academia or just had a little bit more free time I would definitely start working on a JavaScript VM written in JavaScript. That would not be the first project even for JavaScript because people from Université de Montréal kinda got there first with Tac
Samurais had something called bushido, way of the warrior, code of conduct they had to follow. In similar manner you have to follow certain opt-dō if you want to optimize your application. I have tried to sketch such a path in my nodecamp.eu talk “Understanding V8” and +Daniel Clifford tried to do the same in “V8 Performance Tuning Tricks” talk on GDD11 in Berlin. But not everybody has seen those
Disclaimer: This is my personal blog. The views expressed on this page are mine alone and not those of my employer. This post is about JavaScript performance but I would like to start it by telling a story that might seem unrelated to JS. Please bear with me if you don’t like C. A story of a C programmer writing JavaScript Mr. C. is a C programmer as you can probably guess from his name. Today he
Recently V8’s optimizing pipeline (Crankshaft) got full support for external arrays (aka WebGL typed arrays). One of core NodeJS types - Buffer - is exposed to JavaScript code as an external unsigned byte array so I decided to do a small unscientific benchmark to see the improvement with my own eyes: var LONG_STRING = "qwertyuiop"; for (var i = 0; i < 13; i++) LONG_STRING += LONG_STRING; // force
このページを最初にブックマークしてみませんか？
『blog.mrale.ph』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
