Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The compilation speed is very slow #896

Open
ghost opened this issue Jul 10, 2023 · 7 comments
Open

The compilation speed is very slow #896

ghost opened this issue Jul 10, 2023 · 7 comments

Comments

@ghost
Copy link

ghost commented Jul 10, 2023

It's even slower than g++ -static. Is it the parsing that is slow or the code generation that is really slow?

@LADSoft
Copy link
Owner

LADSoft commented Jul 10, 2023

It is the parsing. Perhaps the template engine needs a rewrite, I don't know. Last time I profiled it the main problem was with the time it spent doing new() and delete(). I had made a slight improvement at some point but the improvement became problematic so I (temporarily) backed out of it.

FWIW it is better than it was a few months ago...

@LADSoft LADSoft closed this as completed Jul 10, 2023
@GitMensch
Copy link
Contributor

Is there an issue to track "slow parsing"?

@LADSoft
Copy link
Owner

LADSoft commented Jul 10, 2023

um... this one? It is something that is very much on my mind and in between other things I've spent a lot of time on this, what we've got now is a vast improvement over what we had even a year ago, although it is somewhat canceled out do to massive changes to the source code that have also occurred in the meantime...

@LADSoft LADSoft reopened this Jul 10, 2023
@LADSoft
Copy link
Owner

LADSoft commented Jul 19, 2023

i have another idea about this lol... I'm gonna work on other stuff for a while though...

@LADSoft
Copy link
Owner

LADSoft commented Aug 5, 2023

that didn't pan out, but now I realized that type parsing can be expensive and types are parsed at least twice (sometimes three or more times) before they are finalized... well maybe tomorrow I will work on prototyping a solution for that...

@GitMensch
Copy link
Contributor

ping and the question: which part is considered to be too slow - parsing only (and there only specific parts)?

@LADSoft
Copy link
Owner

LADSoft commented Aug 27, 2023

mostly it is the parser. I tried something else but it didn't pan out lol... there is another idea on the table that I want to explore but I haven't gotten there yet. Basically, I'm not sure orangec isn't still compiling way too many functions that it isn't necessary to compile, and if I can bring that count down I can speed up the compile (so goes the theory lol). I worked on that issue before and to the extent I was able to improve the situation the compile did speed up...

In some cases the optimizer can also stall... this is mostly only seen on some problematic stuff like some of the cobc tests, or when compiling a huge amalgamate like sqlite3. This got a little worse during my current rewrites for libcob but I threw in the 'new/delete' caching I had put in the parser and brought it back down a bit...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants