I'm new to codewars and you don't need to be so condescending [...] I'm still unsure why it doesn't work and you've marked it as resolved when for me it isn't

JohanWiltink marked it resolved because it's inappropriate to use the kata issue system to flag issues in your own solution; issues are counted against the kata and place demands on the community as they take time and energy to resolve. Issues that are not kata related, but rather pertain to difficulties solving would be a major drain on JohanWiltink's time in particular because his role as a mender is to resolve issues in katas. I think you misinterpreted a simple and impersonal record of why the issue was closed as a personal attack.

For kata solving help I recommend heading over to the Discord server (see link in sidebar on the left) where there's a channel set up for that. If you follow the instructions there and set up a thread about your attempt I'm sure someone will be happy to help.

Congrats!

True story, I reverse engineered my solution from steiner787's comment.

Today I chose verbosity.

This seems a little "thin" to me. If we assume that programmer's time is more important than machine time, making the compiler faster at the cost of potential programmer confusion seems like a bad trade-off.

One of C++'s main selling points is speed, so I think it's fair to make the tradeoff for that language in particular. N.B. it doesn't just make the compiler faster, but actually allows the compiler to generate faster code.

A less conventional approach.

That's not available until Node 11, and this is an older kata that hasn't been updated to accept solutions beyond Node 8.

u1 (you won). I can't come up with a shorter comment to reply with.

Nicely done! I agree; I hope this kata gets approved as I appreciate it and all the discussion that stemmed from it.

I forked this solution to demonstrate the effect of a suggestion from Yushi's analysis.

Whether you want to call it micro-optimization or something else, the fact of the matter is that there are solutions that consistently outperform others, and this kata is tuned accordingly. It doesn't improve Big O complexity, but rather it operates on the hidden coefficients and moves the needle for average case performance. While I can appreciate that in C++ land it's common practice to analyze assembly code, in dynamic languages it's common to compare code snippets via benchmarks and empirical evidence.

I don't think it's a fair characterization to say that the things that were tried were blind shots in the dark, especially in light of Yushi.py's detailed explanation and one of his points in particular. Nor do I agree that we need to see an analysis of compiled bytecode instead of a benchmark - the results are non-anecdotal and speak for themselves.

I'd expect a convincing explanation to be at least something like this.

Expectation is the root of all heartache.

Had some fun with this one.

One small nit for the JavaScript version is that the use of snake case in method and variable names runs contrary to convention.

No, thank you - that brought so much clarity to a phenomenon I'd observed but hadn't fully understood.