Deep JavaScript: Theory and Techniques

by ingve • 6 years ago

206 50 6 years ago

_urga5• 6 years ago

One of the things I love about JavaScript is that you can write an almost 10x faster hash table than the standard library if you take care of cache misses and GC: https://github.com/ronomon/hash-table#motivation

In fact, all the usual low-level optimization techniques like reducing branch mispredictions and expensive memory accesses apply, and make a huge difference, even though you're writing in a high-level language.

zamalek• 6 years ago

It's why managed languages have such a bad rap: people think that this stuff ceases to matter.

I remember the C# DirectX billboard sample, it was something like 10x slower than the same C++ sample in the same version of the SDK. Why? C# didn't have generics yet, and a value type was being stored in a non-generic list. Something like 4MB of memory was being copied around due to boxing and unboxing.

These things always matter.

_bxg14• 6 years ago

*for a very specific use-case where you have an ungodly amount of data to insert

Still, it's interesting that there is something to be gained under these circumstances. I'm typically skeptical of this sort of thing because the standard library is written in C++. One time I thought I was very clever and hand-wrote a more appropriate sorting algorithm for a specific use-case only to discover that, no, Array.sort() was still faster by sheer brute force.

austincheney• 6 years ago

The algorithm for Array.sort is implementation specific, but there is an ECMAScript proposal for a standard algorithm.

_urga5• 6 years ago

We actually wrote the original version in C with SIMD extensions as a Node.js binding, but the JavaScript version was still twice as fast. I kid you not. You will find the reason for this in the README, it's the last bullet point under "Fast": https://github.com/ronomon/hash-table#fast

game_the0ry5• 6 years ago

I do appreciate the effort the author put into that library and obviously performance is important.

However, JS doesn't primarily live in the server side world, it mostly lives in the browser world. And in the browsers, you rarely do heavy processing. If you are, you're doing it wrong - that logic needs to live on the server.

You're also doing it wrong in you are relying on server side NodeJS for tasks that involve heavy duty computations.

Still, interesting to know. I wonder if the author can make this repo a proposal to the TC39 committee.

_bxg14• 6 years ago

And in the browsers, you rarely do heavy processing. If you are, you're doing it wrong - that logic needs to live on the server.

This is very incorrect. At my last company we had a React interface (a specialized IDE, really) that needed to juggle (sort, filter, process) and work with sometimes hundreds of thousands of entities at once, all in-memory. JavaScript did this just fine, and the user experience (and the API design) really benefitted from not having a bunch of extra round-trips to the server.

Even in this extreme use-case, the bottleneck was always the few-hundred items that were actually rendered in the DOM at a time. We virtually never had performance problems from sheer volume of underlying data.

hombre_fatal• 6 years ago

I consider this wrong on all counts and I don't see where you're coming from to make these claims. You obviously benefit from performance gains on the server and client in standard use-cases.

A Node.js server's main thread is nickel and dimed by a thousand little cuts. A faster hash implementation can reduce loop delay by a nontrivial amount. This isn't heavy processing.

Same with the client. Any sort of game could have a good reason to be doing hashtable lookups in a hot loop on the client. This isn't heavy processing in some exotic use-case, it's rather elementary. And perf trade-offs especially help slow clients. And freeing up the main thread lets you fit in more nonreducible cycles.

Also, moving work to the server because your client implementation is too slow and then generalizing that to "always do work on the server", is tautological. Where you do work is fundamentally a business logic / product design concern that is only a performance concern in the suboptimal case where you can't fit the work on the server or client. So faster implementations move what are performance concerns back into the realm of higher level product design decisions.

These aren't symptoms of "doing it wrong". This is just plain jane software engineering.

ralphc• 6 years ago

One of the selling points of tensorflow.js is that you do your processing on the client, for privacy reasons. This is heavy, heavy processing, and you're doing it right.

seph-reed3• 6 years ago

I just think this is interesting. The following statement is true:

`(~~4.2 === 4) && (~~-3.5 === -3)`

XCSme5• 6 years ago

Isn't `true` the expected result? Apart from that, who would write code like this?

ipnon2• 6 years ago

Antagonistic JavaScript code golfers typically are not JavaScript users, I've found.

edit: It's like writing an intentional buffer overflow in C. You don't see it as often because it requires actually knowing how to program.

mrspeaker• 6 years ago

Now I'm curious what result the OP was expecting... that's how bitwise NOT should work on (IEEE 754) floating-point numbers regardless of the language, isn't it?

  (4.2).toString(2);
  > "100.00110011001100110011001100110011001100110011001101"
  (~4.2).toString(2);
  > "-101"
  (~~4.2).toString(2);
  > "100"

Perhaps the initial NOT is supposed to maintain the bits after the point? I have to go look at the spec.

[Ok, looks like that not defined in the spec, and is a language-specific behavior: I have some homework now!]

seph-reed3• 6 years ago

I wasn't intending to be antagonistic.

It's just interesting that it works.

ipnon2• 6 years ago

I've never heard of object sealing or freezing, glancing at the Table of Contents. JavaScript keeps surprising me.

  // Levels of protection: preventing extensions, sealing, freezing
  Object.preventExtensions(obj)
  Object.seal(obj)
  Object.freeze(obj)

DylanSp• 6 years ago

From using immer[1], I learned about Object.freeze(), which immer uses under the hood.

[1] https://github.com/immerjs/immer

cjones26• 6 years ago

Though I recommend to my team to avoid mutation if at all possible, there are times which I have found immer absolutely invaluable. Try spreading out an object 15 levels deep to replace a single property value and you'll catch my drift.

XCSme5• 6 years ago

This feature feels pretty new, even though it was released in ES5, and had some more fixes in ES6. It's useful for having immutable data, which was all the hype when React and Redux were introduced.

adamc• 6 years ago

Disappointed not to see a dead-tree version.

tempodox• 6 years ago

This looks like it's worth a place in an electronic bookshelf. Among other things, following a link in the contents led me to this little pearl: https://mathiasbynens.be/notes/globalthis

ezequiel-garzon• 6 years ago

He’s great! Consider https://mothereff.in/ampersands

jacobr• 6 years ago

That’s horrific and amazing

MatekCopatek• 6 years ago

Love this!

Some languages are typically taught in introductory programming courses - it's a very deliberate process aimed at explaining concepts from the ground up. JS is the opposite, people mostly learn it top-down, doing web development and being forced to use it.

And like eager college graduates need to learn it's sometimes a waste of time to optimize an algorithm, DIY JS devs can greatly benefit from a bit of theory and technical depth. Resources like this are perfect for that.

I can also wholeheartedly recommend Kyle Simpson's You Don't Know JS.

azangru• 6 years ago

Have you seen that Flanagan's JavaScript the Definitive Guide, the famously big book with the rhinoceros on its cover, has recently seen a new edition? I wonder how deep its JavaScript goes :-)

(https://www.amazon.co.uk/JavaScript-Definitive-Guide-David-F...)

petercooper• 6 years ago

David has written about what's new, if anyone's interested: https://davidflanagan.com/2020/05/03/changes-in-the-seventh-...

I also (briefly) interviewed him about it here: https://superhighway.dev/david-flanagan-interview

ithrow• 6 years ago

No PDF version?

jmchuster2• 6 years ago

I've always enjoyed the famously small book "Javascript: The Good Parts", albeit a bit dated at this point

mayank2• 6 years ago

Unfortunately, the language has changed so much in recent years that I wouldn’t necessarily recommend that book anymore. A large number of fundamental features have been introduced since 2008, including async/await, lambda functions, class and extends syntax, proxies, and a ton of builtin methods like map() and forEach() on native list types.

divbzero• 6 years ago

A few bits of deep JavaScript that I’ve learned from Deep JavaScript:

– The % operator calculates the remainder, not the modulus, which makes difference for negative numbers.

– Constructors can return a Promise.

– Function names are stored as the .name property.

Deep JavaScript: Theory and Techniques

Related Stories