3 ms·
There was a weird period in JavaScript’s history where the threshold for inlining was rather fixed and counted comments as part of the function weight. So there
by hinkley 10mo ago
There was a weird period in JavaScript’s history where the threshold for inlining was rather fixed and counted comments as part of the function weight. So there was code that would go faster if you deleted the comments.
I believe it was counting AST nodes rather than bytes, otherwise that would have also created problems for descriptive function names as well and that would have been what we heard about instead of comments.
- koyote 10mo agoI ran into a similarish issue in C++ (MSVC++) where a small change that improved an error message led to a 10% slowdown. The function was something like: int ReturnAnswerIfCharIsValid(char* c) { if(c == nullptr) throw std::exception("ERROR!"); return 42; } The exception line was changed to something like: throw std::exception("Char is not valid, please fix it!"); // String is now longer The performance of this hot-path function went down the drain. I fixed it by replacing the exception call with yet another function call: if(c == nullptr) ThrowException(); Other fixes might have included something like __forceinline in the function signature.
- hinkley 10mo agoIt’s weird that something that should be in a constants pool would hit the inlining threshold.