mraleph

27 ms·

1. 271.▲
   by mraleph 15y ago

   Probably not. Everything is there in the deck. If people will have a lot of questions about slides (there is nothing novel there though) I can do a follow up post.
2. 272.▲
   by mraleph 15y ago

   Just ask if you are interested in something.
3. 273.▲
   by mraleph 15y ago

   Unfortunately the talk was not recorded. There is no transcript either.
4. 274.▲
   by mraleph 15y ago

   Because: 1) const is not supported by an optimized compiler and any function that declares or references const variable will not be optimized; 2) const is slower than var because it has a more complicated semantics;
5. 275.▲
   by mraleph 15y ago

   I am very sorry about unintuitive interface, but these are slides for the talk I gave on nodecamp.eu, not a website. I'll add a note on the first slide as soon as I get home.
6. 276.▲
   by mraleph 15y ago

   Right title for this 2 years old article is "Why V8 is not suitable for nginx". He has his own set of requirements which by no means applies to _all_ webservers.
7. 277.▲
   by mraleph 15y ago

   Array is intended to be a mutable storage with a fast random access and optimistic preallocation of backing store. String is intended to be an immutable storage. At least that's how I see these types. I also would not expect that VM will us
8. 278.▲
   by mraleph 15y ago

   Array is an appropriate datastructure for this algorithm. String is not. var dest = 'apple'.split(''); var j = dest.length; var start = new Date(); while (j < 100000) { var offs = j - 5; for (var i = offs;
9. 279.▲
   by mraleph 15y ago

   Crockford's code style is very peculiar: https://github.com/douglascrockford/JSLint/blob/master/jslin... (I really hope that this is not coding-style-of-the-future) As you can see single Object.create callsite becomes a construction site
10. 280.▲
    by mraleph 15y ago

    I think Mozilla is also making SpiderMonkey threading model more strict. https://developer.mozilla.org/en/JS_THREADSAFE says: JS_THREADSAFE is now permanently on. We have recently made major changes to this feature. Until recently, sharin
11. 281.▲
    by mraleph 16y ago

    Yeah, I did something stupid in my own test. Probably I was thinking about Object.seal(). Nevertheless your own test revision #3 shows that accesses to frozen properties are roughly 14 times slower. Revisions #5 and #6 do an allocation in t
12. 282.▲
    by mraleph 16y ago

    Currently doing Object.freeze closes the door for optimizations: object goes into so called slow mode. See http://jsperf.com/object-freeze results.
13. 283.▲
    by mraleph 16y ago

    A process crash will cause the same problem for thread-per-connection server. There is essentially no difference in stability between thread-per-connection and event-loop based servers.
14. 284.▲
    by mraleph 16y ago

    I don't know node.js well enough to even make a guess here. Somebody needs to profile it. Updating your post sounds like a nice idea. It created a lot of confusion among developers.
15. 285.▲
    by mraleph 16y ago

    Speaking about GC behavior of other benchmarks: 1) one with Buffers is also causing mark-sweep/compact pauses (7-15ms each) because Buffer constructor calls AdjustAmountOfExternalAllocatedMemory which triggers full gc cycle if it thinks tha
16. 286.▲
    by mraleph 16y ago

    You were saying that V8 GC is failing here so I just explained why JSON.parse is especially bad for V8 GC. Strictly speaking I am not even convinced that GC is bottleneck here. Only profiling can reveal the real bottleneck. [I tried small e
17. 287.▲
    by mraleph 16y ago

    --trace-gc will show an endless sequence of mark-sweep/compacts. I explained why that happens in my comment to the original post.