speed up compiler

[LADSoft]

i have a working set where the compiler operates between 15 to 60 percent faster for C++ code, depending on the source file. I found that the biggest issue is the compiler compiles a lot of unused functions... there is still cleanup to be done there so I can get it a little faster...

[GitMensch]

Just to check: This issue is planned to be finished "relative soon", right?

Do you have any experience about C generation performance?

[LADSoft]

yes the immediate road map is to finish the work on #971, which basically means getting everything that build.bat does to compile and run again. After that I merge with my other branch that has other pending issues and test the whole thing together. That has part of the speedup stuff done so it is a little better. When I get that done I do a push to github then I go back to this issue and finish up the next part of the problem. After that I have one other thing to do related to the covscript work I was doing before. Then I'm going to go on and clean up any other easy issues that are on the plate before moving on....

Im hoping to have it compiling again this weeked and do the push.

As far as experience with C generation performance, not really. But the performance issues we are seeing are like other things I've had with this , the design of this thing is so complex I can't keep enough of it in my head to fully understand all the ramifications of the designs I am making. In the present case, I finally figured out how to read the data from the profiler I use, and decided that way too many functions are being compiled and that is wasting a lot of compile time.... and started analyized the code to see why. Some basic issues have been fixed but there are a couple more, such as evaluating default argument expressions while trying to choose an overload match, and creating constructors for inline data even when that data isn't used in the current source file. And there may be others I haven't found yet.... I was excited about fixing those to see what it could do but then I got caught up in #971....

[LADSoft]

need to make a note to retest #1077 when I'm through with this.

[LADSoft]

@GitMensch
im still contemplating what to do about speeding up OCCPARSE.... the ideas i had don't really pan out although there is merit to fixing the inline data issue... i looked at occopt working on expr.cpp in the profiler though. i did figure out though that for OCCOPT the low-hanging fruit is bit arrays. Especially sparse ones. Simply not allocatng bit arrays or using them for math in certain situations (such as the live variable analysis) should speed things up nicely. It will also improve memory usage some more... std::set or maybe even std::unorderd set can be used for set unions and intersections which was the point of the bit arrays in most cases... and snce the bit arrays are sparse anyway it shouldn't be a problem. Which all that does make a difference because occopt can take 25 or 30 percent of the total compile time... so for something like expr.cpp that takes maybe 12-14 seconds to compile with occ when occ is compiled with msvc... 9 seconds of that is occparse and 3 is occopt.

@chuggan i thought about a new way of doing gcse while in SSA form some more. while i think we can do better speed and memory wise for gcse, i think that in addition to that the side benefits such as being able to get rid of part of the aliasing code and one round of SSA transitions, along with everything that goes with that second round of transitions, are likely a bigger benefit....

I don't know that I want to do all that immediately though. I want to see if I can find anything else in occparse in the short term, then get started writing the new backend..... so this issue will likely hang around until I need a break from that lol... I've been meaning to lay out my plans for the new backend in the discussions area so you can get the general drift of where I want to go with it. ive decided to adapt to what you said about moving everythng we can into the backend so that will be the first step...

[LADSoft]

after several weeks working on this, I've managed to get occparse to compile between 30 and 50% faster depending on the source files. the times for occopt when down modestly as well due to some of those changes. when occ is compiled with MSVC, the benchmark @chuggafan posted funs at about 2.1s, down from just over 5. I'll close this after I push the changes although that won't stop me from trying again later.

[chuggafan]

Nice!
I feel that we use templates relatively sparingly, but a 100% speedup approximately (Time is halved) even in this file, could mean an occparse speedup of 10% on our builds(?). Sounds like we may actually start to be fast on appveyor again, depending....
I'll redo my timing tests at some point for full builds soon(ish), now that I have build.bat functional.

[LADSoft]

i think the time is down on my builds... and I'm definitely seeing some impressive speedups when I'm compiling the tests, I've played with some of them long enough to know about what to expect... I'm hoping too we can get appveyor back on its feet 😄.

I've thought about the template thing... it seems like that would be a big part of the problem but it never shows too high on my profiler. The big thing is always new/delete, which I made a patch for that by putting in fixed pool allocations. Something else that always shows high is the symbol table lookups sigh... A lot of the time is still spent while compiling functions, I need to look into that and see if I can find something like the 'compiling too many functions' thing I guess sigh...

[LADSoft]

so after yesterday I got an idea to just compile the headers from expr.cpp by themselves. That takes 3.8 seconds in occparse, as opposed to about 7.1 for the entire file... I'm wondering if I don't compile structured template definitions immediately will that help? The main reason I never did that is I don't know how to correlate functions defined outside the template body, to the template, if the template hasn't been compiled... but maybe it is worth thinking about...