A death by a thousand cuts. That’s what the CPU overuse problem really amounted to. By finding a few files that produced the problem, and then spending quite a bit of time in the YourKit profiler, I was able to find a number of places that created small delays, each relatively inconsequential in themselves. As I was attacking each of them, I kept wondering, “Is this the big issue? Is this the smoking gun?” Well, yes and no, as it turns out.
The primary issue was that resolution was slow. It was slow because it was re-doing a lot of work. Adding caching was a help, but no magic bullet. Parsing, itself, was still too slow. In the end, the parsing culprits turned out to be String.split(), the streaming Collections.collect() interface, and parsing float values — all Java intrinsic functions. The answer turned out to be: don’t do those things. Replacing and/or avoiding each of them saved time incrementally.
As it stands, parsing and annotation processing are about ten times as fast as they were. That leaves more time in the UI thread so that colorizing and annotating the sources no longer appear to delay user’s typing response.
What I did for my sponsors:
1) CPU Over-use bug. Profiling, code path optimization. (Complete? In testing.) (Also fixes bug #851)
What I did for the Community:
1) Small number of code reviews.
2) Some work on fixing the debugger launching the wrong configuration when HXML or custom configurations are used.
Community Contributions (Thanks to Alexander Kuzmenko):
1) Auto-setup of the Haxe SDK for new projects.
2) Auto-setup of the Haxe SDK for projects imported from source.
3) Auto-setup of libraries and run configuration when importing from sources.
1) Resolve overlap between my Haxe SDK work and Alexander’s; finish new UI for standard library locations.
2) Release 11.1 (not 11.3 — we are currently at 11.0.2)
3) (Stretch) More work toward parsing and syncing project files, leading to the automatic managing for compiler conditional problems.