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 really takes time in some cases with ocaml trunk (4.02) #6350
Comments
Comment author: @alainfrisch The obvious candidate is the introduction of module aliases. Since it's easier for you to test it, can you check if the problem started to materialized at revision 14394? |
Comment author: jpdeplaix I just check with the revision just before 14394 and it doesn't appear. |
Comment author: jpdeplaix Yes, it's definitively that. We've thought of that but we didn't managed to reproduce it (even if Luc tried his best to play with module aliases). |
Comment author: @alainfrisch Thanks for the confirmation! I've thus assigned the ticket to Jacques. |
Comment author: @garrigue That's a rather mysterious problem. Still investigating. |
Comment author: jpdeplaix Weird. For me, with -i it takes around 20 seconds and for -dtypedtree and -drawlambda it takes around 50 seconds. |
Comment author: @garrigue Sorry. I was wrong. |
Comment author: @garrigue Sorry again, it's not Includecore, but Includemod.signatures. |
Comment author: @garrigue Localized the problem to Ctype.moregen. |
Comment author: @garrigue The cause was repeated substitution in the functor application case of Env.find_module. Fixed in trunk, revision 14482. |
Comment author: jpdeplaix Thanks ! Note also that the global compilation time increased a little bit (116s => 141s) |
Comment author: @garrigue I see. Fixed at revision 14483. |
Comment author: @garrigue Sorry, I was wrong again. Note that on very big projects using lots of module aliases, like Core, we actually see |
Comment author: jpdeplaix Thanks. I just tried, and on 4.02 (with your patch) the compilation takes:
So we can see a 10s slow down (which is not really big) if we compare the program built the same way. |
Comment author: @alainfrisch Any reason to believe that the slowdown is related to type-checking? There have been changes in ocamlopt, which could explain a tiny compile-time overhead (but 8.5% seems a lot). |
Comment author: @garrigue I've done some further measurements, comparing 14393 with a fixed version of 14394 and the current trunk. make (in herdtools) |
Comment author: @alainfrisch Thanks for the analysis! I'm wondering whether we should put in place some more automated way to detect performance regression of the compilers, maybe using allocation as a stable proxy for speed. One way to do it would be to measure total allocation e.g. when compiling each unit to produce ocamlc.opt, storing this value in a text file which will be compared with a "reference" (modulo some admissible error) during one of the tests in testsuite/. |
Comment author: @garrigue That would be clearly useful. |
Original bug ID: 6350
Reporter: jpdeplaix
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2017-02-16T14:16:14Z)
Resolution: fixed
Priority: normal
Severity: minor
Fixed in version: 4.02.0+dev
Category: typing
Tags: compiler-time-or-space-regression
Bug description
With the following « test-case », you will see that SemExtra will takes a considerable amount of time to compile (more than 40 secondes on my machine).
It seems that the problem is in the typer because the parsetree is well displayed with the -dparsetree option but not with -dtypetree.
Note also that if we remove the type annotation line 165, then it take half the time to compile (about 23 secondes).
Steps to reproduce
Sorry but Luc and I, failed to reproduce it in a small test-case.
So, our case is for this file (and all module that does an include of SemExtra.Make, applied): https://github.com/herd/herdtools/blob/master/herd/semExtra.ml
If you want to test it, you can clone the repo and execute « make -C herd » (no dependencies needed).
Additional information
Of course, in 4.01, the compilation was instant.
The text was updated successfully, but these errors were encountered: