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

Accelerer le typage en memoisant Env.components_of_functor_appl #4132

Closed
vicuna opened this issue Oct 8, 2006 · 5 comments
Closed

Accelerer le typage en memoisant Env.components_of_functor_appl #4132

vicuna opened this issue Oct 8, 2006 · 5 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Oct 8, 2006

Original bug ID: 4132
Reporter: @alainfrisch
Status: closed (set by @xavierleroy on 2006-10-13T12:58:23Z)
Resolution: fixed
Priority: normal
Severity: tweak
Category: ~DO NOT USE (was: OCaml general)
Monitored by: ertai @alainfrisch

Bug description

(Suite à une discussion avec Xavier)

La compilation du nouveau Camlp4 prend beaucoup de temps. On peut accélerer
le typeur de manière significative en memoisant la fonction Env.components_of_functor_appl. Par exemple, sur ma machine, la compilation de Camlp4/Struct/Camlp4Ast.ml (preprocessing exclus) passe d'une minute à 1.5s.

Steps to reproduce

J'ai simplement fait comme ci-dessous. Il faudrait peut-être nettoyer
la table entre deux compilations (id uniques réutilisés ?).

let memo_components_of_functor_appl = Hashtbl.create 1024

let components_of_functor_appl f p1 p2 =
let key = (f.fcomp_param, p1, p2) in
try Hashtbl.find memo_components_of_functor_appl key
with Not_found ->
let p = Papply(p1, p2) in
let mty =
Subst.modtype (Subst.add_module f.fcomp_param p2 Subst.identity)
f.fcomp_res in
let c = components_of_module f.fcomp_env f.fcomp_subst p mty in
Hashtbl.add memo_components_of_functor_appl key c;
c

@vicuna
Copy link
Author

vicuna commented Oct 9, 2006

Comment author: ertai

C'est tout de même deux fois plus rapide pour compiler Camlp4 :)

@vicuna
Copy link
Author

vicuna commented Oct 9, 2006

Comment author: @alainfrisch

Autre optimisation sensible: appliquer de manière paresseuse la substitution pour calculer les comp_modules dans Env. C'est utile lorsque l'on a une longue signature avec plein de sous-modules et qu'on n'en utilise qu'un petit nombre.

...
mutable comp_modules: (string, (module_type Lazy.t * int)) Tbl.t;
...
| Tsig_module(id, mty, _) ->
let mty' = lazy (Subst.modtype sub mty) in
c.comp_modules <-
Tbl.add (Ident.name id) (mty', !pos) c.comp_modules;
...

et les Lazy.force là où il faut.

Je gagne de l'ordre de 13% sur la compilation de tout Camlp4.
Sur un module comme Camlp4Parsers/OCamlParser, ça passe de 2.44s à 1.38s.

@vicuna
Copy link
Author

vicuna commented Oct 9, 2006

Comment author: @alainfrisch

Cela indique peut-être qu'il faudrait utiliser "module_type Lazy.t" un peu partout dans le code (y compris dans la définition de module_type, sauf que l'on veut pouvoir sérialiser...), pour éviter des substitutions sur de grosses signatures qu'on n'utilise que partiellement.

@vicuna
Copy link
Author

vicuna commented Oct 9, 2006

Comment author: @alainfrisch

On gagne encore autour de 8% dans la compilation de Camlp4 en faisant des substitutions paresseuses pour les signatures:

...
| Tmty_signature of signature Lazy.t
...

dans Subst.modtype:

| Tmty_signature sg ->
if s.for_saving then
Tmty_signature((Lazy.lazy_from_val(signature s (Lazy.force sg))))
else
Tmty_signature((lazy(signature s (Lazy.force sg))))

et des Lazy.lazy_from_val et Lazy.force un peu partout.

@vicuna
Copy link
Author

vicuna commented Oct 13, 2006

Comment author: @xavierleroy

Implemented cacheing for applicative functors + lazy substitution for module types stored in comp_modules. To keep changes localized to typing/env.ml, I'd rather not make module_type lazy everywhere else.

@vicuna vicuna closed this as completed Oct 13, 2006
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant