This. Also the applicability of the optimization rule depends a lot on the context. It is typically stated for a complete project. Writing a library is different from that.
Depending on the kind of library you write, it could be that it is called in a hot inner loop of an outer project. So yes in that case it would make fully sense to optimize the heck out of the complete library (like e.g. a mysql client).
Another point is to see the reasoning behind the optimization rule. Optimization always is associated with cost (cost of programming, additionaly complexity in the code, maintance). This cost has to be recovered from the effects of the optimization. As the number of users for a piece of code grows, the benefit of optimization rises, but the costs should be more constant. Thus at scale it also makes sense to look a smaller optimization potentials.
But this does probably apply to not even 1% of the typical projects.
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.)
While one problem the blog post describes is valid, I think the authors comes to the wrong conclusion. The problem is that the method is implemented in such a way that it uses Integer objects which are different from the native integer types.
Objects have very clear semantics concerning the == operator. It checks whether the object identity is the same (alas it is the same object). There is nothing special about it, thats also the reason why you can't compare two strings with == and this is s.th. I think every Java developer learns within the first days/weeks (often by first doing it wrong, I don't claim that this is intuitive).
So in this light the correct solution, which the author even does not mention anymore in the end, would be for the method to use the a.equals(b). Everything would work. The point of the author that a team should agree on using either one or the other is nonesene, because in some situations there is no choice (e.g. HashMaps only work with objects). Also there is no real problem, because whoever implemented the method know what he gets and should have implemented it using the equals method. So in reality this should not be fixed with creating seperate Integer instances but with fixing the method itself.
As a last comment, there is one pitfall to watch out for with autoboxing. When you use the "int" type in your code and call a method which returns an "Integer" and you compare with == you can get wrong results. I think of this as a real problem, because often you know that a method will return a number but you don't expect it to be returned as Integer. Or even worse between versions of the api the method is changed from returning int to Integer and you don't even notice because it compiles. But I think this happens very rarely and personally I always return numbers as native types.
PS: But I can understand that it is sometimes confusing that the code is working in some cases and not working in others, when it should never work! If you want to get a really good understanding of the semantics of the Java language I would advise to read ( http://java.sun.com/docs/books/effective/ )
The author ( me :P ) mentions that using a.equals(b) is the correct solution right at the beginning of the post. Unfortunately this problem will continue to occur as long as autoboxing exists, so I think it's a valid idea to simply enforce a rule across your team that says 'Here's how we're going to avoid autoboxing problems'. I intended this post to be more of an illustration of what autoboxing does.
With regards to your comment that the solution is not to create separate integer instances - I was attempting to show that this is a possible solution to autoboxing headaches rather than 'the correct' solution for testing integer equality, because the objects are not cached. Sometimes you want to use == for valid reasons, the problem I had was because I wasn't vigilant enough in checking my own code and used == when I shouldn't have used it in the first place.
Perhaps this post could have been written more clearly - but as it happens, you're spot on. The examples at the end of the post were intended to be potential solutions to autoboxing headaches in general, rather than a solution for my specific problem :)
Ok, in that regard I think your post was very informative. Raising awareness of this language detail is very important, because it can lead to bugs which are very hard to detect.
The two most valuable advices from your post is directly the first line (but I have to admit that I overread it the first time I looked at the post). And second to use some tooling like the Eclipse code checker or findbugs (which was mentioned in another comment) to make implicit conversions visible to the programmer.
The only point I still disagree, though this is only a minor point, is that even with your explanation the possible solution of creating seperate instances is really no help. My point beeing that either you know that autoboxing occurs at a point and one can handle it correctly, or one doesn't know and in that case you also can't create seperate integer instances. This is from the point of view of someone who worked most of his career with Java and that line just makes my eyes bleed. But I can also understand if this looks like nitpicking to others ;)
