Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006350OCamlOCaml typingpublic2014-03-20 13:462014-03-25 10:47
Reporterjpdeplaix 
Assigned Togarrigue 
PrioritynormalSeverityminorReproducibilitysometimes
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.02.0+dev 
Summary0006350: The compilation really takes time in some cases with ocaml trunk (4.02)
DescriptionWith 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 ReproduceSorry 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 InformationOf course, in 4.01, the compilation was instant.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0011063)
frisch (developer)
2014-03-20 14:07

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?
(0011065)
jpdeplaix (reporter)
2014-03-20 14:55

I just check with the revision just before 14394 and it doesn't appear.
I'm checking for the revision just after.
(0011066)
jpdeplaix (reporter)
2014-03-20 15:07

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).
(0011067)
frisch (developer)
2014-03-20 16:34

Thanks for the confirmation! I've thus assigned the ticket to Jacques.
(0011070)
garrigue (manager)
2014-03-21 09:29

That's a rather mysterious problem.
A more careful analysis shows that the problem occurs not during typing, but after
(compiling with both -i and -dtypedtree is fast, but -drawlambda is slow).
However, the generated lambda code is almost identical up to renumbering of identifiers.
So this has to be happening during the conversion from typedtree to rawlambda.

Still investigating.
(0011071)
jpdeplaix (reporter)
2014-03-21 10:34

Weird. For me, with -i it takes around 20 seconds and for -dtypedtree and -drawlambda it takes around 50 seconds.
(0011072)
garrigue (manager)
2014-03-21 11:31

Sorry. I was wrong.
The slowdown is circumscribed down to Includecore, but I didn't find the cause yet.
(0011073)
garrigue (manager)
2014-03-21 11:34

Sorry again, it's not Includecore, but Includemod.signatures.
(0011080)
garrigue (manager)
2014-03-22 15:31

Localized the problem to Ctype.moregen.
It has exactly the same number of calls (including recursive calls),
but is 80 times slower... very strange.
(0011081)
garrigue (manager)
2014-03-22 16:52

The cause was repeated substitution in the functor application case of Env.find_module.
Solved it by adding a cache, like was already the case for components_of_functor_appl.

Fixed in trunk, revision 14482.
(0011082)
jpdeplaix (reporter)
2014-03-22 18:08

Thanks ! Note also that the global compilation time increased a little bit (116s => 141s)
(0011083)
garrigue (manager)
2014-03-23 01:08

I see.
When called from normalize_path, there is no need to do extra work when the functor result is not an alias.
Could get back the overhead this way.

Fixed at revision 14483.
(0011084)
garrigue (manager)
2014-03-23 03:18

Sorry, I was wrong again.
Probably an erroneous measure.
I can still see a 10% slowdown compared to 14393, both on semExtra.ml and overall.
However, the cause is not normalize_path/find_module.
So it's going to be hard to track it down.

Note that on very big projects using lots of module aliases, like Core, we actually see
a dramatic speed up.
Would have to look at other programs too.
(0011085)
jpdeplaix (reporter)
2014-03-23 09:30

Thanks. I just tried, and on 4.02 (with your patch) the compilation takes:
- 136s
- but 127s with ocamlbuild -no-ocamlfind
compared with 117s on 4.01.

So we can see a 10s slow down (which is not really big) if we compare the program built the same way.
(0011087)
frisch (developer)
2014-03-24 10:03

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).
(0011092)
garrigue (manager)
2014-03-25 03:26

I've done some further measurements, comparing 14393 with a fixed version of 14394 and the current trunk.
The conclusion seems to be that for semExtra.cmo there is indeed a small slowdown (less than 10%) due to the introduction of normalize_path, but for the whole compilation of herdtools, this only accounts for 2% of the slowdown, the rest (8%) coming from more recent changes, probably in the backend.
I also tried with the lablgtk trunk, and I get no slowdown at all from the introduction of module aliases,
and actually a speedup from more recent changes (maybe due to the fact I'm using ocamlopt.opt).
From that I feel like there is no much need to inquire further.

make (in herdtools)
4.01: 74s
14393: 77s
14394+optalias: 79s
14482: 85s
semExtra.cmo
4.01: 1.67s
14393: 1.67s
14394+optalias: 1.80s
14482: 1.80s
(0011094)
frisch (developer)
2014-03-25 09:45

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/.
(0011096)
garrigue (manager)
2014-03-25 10:47

That would be clearly useful.
Currently our only way to know that something went wrong about performance is when some user shouts out...
Also lots of small changes may end up slowing the compiler more and more, without many people noticing
(this said this probably gets hidden by the move to faster machines).

- Issue History
Date Modified Username Field Change
2014-03-20 13:46 jpdeplaix New Issue
2014-03-20 13:48 jpdeplaix Note Added: 0011062
2014-03-20 14:05 frisch Description Updated View Revisions
2014-03-20 14:05 frisch Note Deleted: 0011062
2014-03-20 14:07 frisch Note Added: 0011063
2014-03-20 14:55 jpdeplaix Note Added: 0011065
2014-03-20 15:07 jpdeplaix Note Added: 0011066
2014-03-20 16:33 frisch Assigned To => garrigue
2014-03-20 16:33 frisch Status new => assigned
2014-03-20 16:34 frisch Note Added: 0011067
2014-03-21 09:29 garrigue Note Added: 0011070
2014-03-21 10:34 jpdeplaix Note Added: 0011071
2014-03-21 11:31 garrigue Note Added: 0011072
2014-03-21 11:34 garrigue Note Added: 0011073
2014-03-22 15:31 garrigue Note Added: 0011080
2014-03-22 16:52 garrigue Note Added: 0011081
2014-03-22 16:52 garrigue Status assigned => resolved
2014-03-22 16:52 garrigue Fixed in Version => 4.02.0+dev
2014-03-22 16:52 garrigue Resolution open => fixed
2014-03-22 18:08 jpdeplaix Note Added: 0011082
2014-03-23 01:08 garrigue Note Added: 0011083
2014-03-23 03:18 garrigue Note Added: 0011084
2014-03-23 09:30 jpdeplaix Note Added: 0011085
2014-03-24 10:03 frisch Note Added: 0011087
2014-03-25 03:26 garrigue Note Added: 0011092
2014-03-25 09:45 frisch Note Added: 0011094
2014-03-25 10:47 garrigue Note Added: 0011096


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker