Additional optimizations #22
Conversation
1. Move strings we no longer need 2. Append char to whitespace instead of string (of 1 char) 3. Clear whitespace instead of ``` = "" ``` (tiny speed difference from benchmarking, nice to know anyway) 4. Use ``` const char * ``` for startsWith, avoiding the creation of temporary string objects.
|
Looking really good here :) Do you have any timings for before this PR vs after? I'm getting really good speeds on a 50k+ codebase but I don't have a way of testing against the original flint atm. |
| return mismatch(begin(prefix), end(prefix), str_iter).first == end(prefix); | ||
| bool startsWith(string::const_iterator str_iter, const char *prefix) { | ||
| while (*prefix != '\0' && *prefix == *str_iter) { | ||
| ++prefix, ++str_iter; |
There was a problem hiding this comment.
Had no idea you could do comma separated expressions of this form. Does this actually provide a performance boost?
There was a problem hiding this comment.
No performance boost, no value to doing it that way either to be honest :)
|
On the folly + gtest + double-conversion code base, with stats of Lint Summary: 518 files Estimated Lines of Code: 519422 (seems high? I think something is wrong with the estimate) Flint++: 0m2.918s I'm giving the D version a bit of a pass here, but I'd love to see what they tested on to determine that the D version was faster than the C++ version. In any case, Flint++ is faster than both now and there are still a good amount of optimizations to do (for instance, we're allocating too many strings still). |
|
The estimate was really an estimate haha. It was just the number of I'll work on a better metric if we are going to keep it in. |
|
Additionally facebook have mentioned here and there in comments their Tokenizer gets confused by complicated template<> usage. Something gtest has a lot of. I fixed a couple of these issue early on in the rewrite so I think we're doing well compared to them atm. |
After some serious Valgrind profiling love:
This PR also includes the optimize strings PR. Kept that open because I put a couple additional comments there.
Unordered_map is faster for lookup, O(1) vs O(logn). We profiled them previously with GCC 4.8.1 to make sure, it holds even for small collections.