Opened 6 years ago
Closed 5 years ago
#16380 closed enhancement (fixed)
improve startup time of libGAP
Reported by: | dimpase | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-6.3 |
Component: | interfaces | Keywords: | libgap, startup time |
Cc: | vbraun, ncohen, wdj | Merged in: | |
Authors: | Volker Braun | Reviewers: | Travis Scrimshaw |
Report Upstream: | N/A | Work issues: | |
Branch: | 02a25d5 (Commits) | Commit: | 02a25d5626c0527e81559d3229ac6b6f64d35978 |
Dependencies: | Stopgaps: |
Description (last modified by )
currently libGAP loads slower than GAP with pexpect interface.
$ ./sage --nodotsage Sage Version 6.3.beta1, Release Date: 2014-05-13 │ sage: sage: gap("1") 1 sage: Exiting Sage (CPU time 0m0.22s, Wall time 0m21.87s). Exiting spawned Gap process. nash:sage dima$ ./sage --nodotsage Sage Version 6.3.beta1, Release Date: 2014-05-13 │ sage: libgap("1") "1" sage: Exiting Sage (CPU time 0m7.06s, Wall time 0m16.95s).
About extra 7 sec on a Core2 x86_64
machine, at least according to the CPU time report, which might be lying(?).
The main issue is in saving/loading a GAP workspace, which is not done by libGAP
at the moment. See also https://bitbucket.org/vbraun/libgap/issue/2/workspace-support
Change History (12)
comment:1 follow-up: ↓ 3 Changed 6 years ago by
comment:2 Changed 6 years ago by
Why is libgap
linked to libgmp
rather than to libmpir
(which are copies of each other, as far as I can tell) ? My understanding is that libmpir
is already loaded at Sage startup, while libgmp
is not. If we are hit by dlopen
slowness, this might be something to consider changing.
comment:3 in reply to: ↑ 1 Changed 6 years ago by
- Description modified (diff)
Replying to dimpase:
in view of
--nodotsage
used, no prebuilt GAP workspace is loaded, thus https://bitbucket.org/vbraun/libgap/issue/2/workspace-support is probably not directly related.
I should retract this, my timings were off. Now I bet that it really is the main problem of slowness on startup.
comment:4 Changed 5 years ago by
- Cc wdj added
- Description modified (diff)
The workspace to load should be created by libGAP
, and not by "normal" GAP
. Then it all works.
Should we mimic the way "normal" GAP deals with the workspaces? Or are there other/better ideas?
comment:5 Changed 5 years ago by
- Branch set to u/vbraun/improve_startup_time_of_libgap
comment:6 Changed 5 years ago by
- Commit set to 02a25d5626c0527e81559d3229ac6b6f64d35978
- Status changed from new to needs_review
comment:7 Changed 5 years ago by
PS: 7 seconds!?! Time to get one of those SSDs ;-)
comment:8 Changed 5 years ago by
- Reviewers set to Travis Scrimshaw
- Status changed from needs_review to positive_review
Goes from ~20s to under 1s (after the second run). This will speed up development for Lie theory and Weyl groups significantly.
comment:9 Changed 5 years ago by
Shouldn't installaing extra GAP packages (in database_gap
and in gap_packages
) trigger libgap workspace updates?
comment:10 Changed 5 years ago by
It does right now because you get the "Forcing sage-location, probably because a new package was installed." which touches libgap.la
. Which, in turn, invalidates the saved workspace. Though that is not a good mechanism, and we probably want to get rid of the sage-location thing. There should be a generic hook to delete cached stuff after installing of packages, but afaik there is none. The GAP interface has the same problem, I think.
comment:11 Changed 5 years ago by
Also, the extra packages are not loaded into the saved libgap workspace. Regardless of whether they are installed or not.
comment:12 Changed 5 years ago by
- Branch changed from u/vbraun/improve_startup_time_of_libgap to 02a25d5626c0527e81559d3229ac6b6f64d35978
- Resolution set to fixed
- Status changed from positive_review to closed
in view of
--nodotsage
used, no prebuilt GAP workspace is loaded, thus https://bitbucket.org/vbraun/libgap/issue/2/workspace-support is probably not directly related.