For me myself it is often very motivating (sometimes demotivating) if somebody comes up and implements the same thing I want to do - but they accomplish 10x faster performance (even better if it is written in a cleaner style). The author seems also to rather enjoy those challenges ;)
In my interpretation the question "Faster than C?" is relevant because it is very easy to think that certain problems (like parsing binary data) are just not a good fit for language Y and thus the performance can't be good. Even if C performance is not attainable sometimes one cat get closer than one would think.
My last question is regarding his optmization example.I don't program javascript and thus have difficulties understanding how the optimized variant could every be faster than the original one. String concatenation and evaluation should not be faster (from my laymans perspective) than setting an indexed value to an array? (Ok actually it probably is not an array but a hash map, but are those so inefficient in java script? Or is it rather behaving like a sorted list where every value is inserted via binarcy search?).I would be very happy to get some insight.
Regarding your last question: the string concatenation/evaluation happens once while creating the parseRow function and from then parseRow is a compiled/JIT'd function object, no string handling happening. The problem with the original is not the hash map creation, but the fact that it requires all sorts of extra loops, and array & property look-ups.
Also, I think that is possibly some missing information there, since in the second version the column names are fixed (so the columns argument to parseRow is ignored), while in the first they are not.
Ah ok so this is probably the parser equivalent to precompiled queries. Given a fixed query, a specific parse row function is created once and than reused. Thanks!
While I think code generation is certainly the right approach in some examples, I see one problem in this example: As the parser is basically pregenerated using a certain column definition, why does the generated function has an parameter columns? It is simply discarded. So I would say it should rather be:
I agree, and I don't know. (I even looked through the source to try to find if parseRow is a function from node-mysql. It's not, as far as I could tell.)
In my interpretation the question "Faster than C?" is relevant because it is very easy to think that certain problems (like parsing binary data) are just not a good fit for language Y and thus the performance can't be good. Even if C performance is not attainable sometimes one cat get closer than one would think.
My last question is regarding his optmization example.I don't program javascript and thus have difficulties understanding how the optimized variant could every be faster than the original one. String concatenation and evaluation should not be faster (from my laymans perspective) than setting an indexed value to an array? (Ok actually it probably is not an array but a hash map, but are those so inefficient in java script? Or is it rather behaving like a sorted list where every value is inserted via binarcy search?).I would be very happy to get some insight.