Hello,
I would like to collect information about the time it takes to compile an ASDF system (possibly also load it), dependencies excluded. I'm thinking there's probably a way to do this by :around'ing compile-op, or something like that, but if someone already has a clear view on how to make this happen, I'd be grateful for the time spared!
Thanks.
Hello,
I would like to collect information about the time it takes to compile an ASDF system (possibly also load it), dependencies excluded. I'm thinking there's probably a way to do this by :around'ing compile-op, or something like that, but if someone already has a clear view on how to make this happen, I'd be grateful for the time spared!
Simplest method: 1- load the dependencies, possibly using (asdf:operate :prepare-op s) 2- (time (asdf:make s))
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I used to like the government, but that was before it got big and popular.
François-René ÐVB Rideau écrivait:
Simplest method: 1- load the dependencies, possibly using (asdf:operate :prepare-op s) 2- (time (asdf:make s))
Nice, thank you. If I want to time separately the compilation and loading phases of several libraries (which may depend on each other) however, I would need to restart my session every single time. Another way to do this and, say, report the timings to a file?
On 5 Dec 2018, at 9:46, Didier Verna wrote:
François-René ÐVB Rideau écrivait:
Simplest method: 1- load the dependencies, possibly using (asdf:operate :prepare-op s) 2- (time (asdf:make s))
Nice, thank you. If I want to time separately the compilation and loading phases of several libraries (which may depend on each other) however, I would need to restart my session every single time. Another way to do this and, say, report the timings to a file?
-- Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
Depending on the host lisp you are using, couldn't you wrap the calls to `COMPILE-FILE` and `LOAD` in code that times those operation?
You could use dynamic variables bound inside the calls to `PERFORM ` to ensure you collect only the information you need, and not other calls to those functions that happen to occur.
In ACL you could use function wrappers (`fwrap`) and SBCL has a similar feature whose name I can't recall at the moment.
Best, R
"Robert Goldman" rpgoldman@sift.info écrivait:
Depending on the host lisp you are using, couldn't you wrap the calls to COMPILE-FILE and LOAD in code that times those operation?
I could, but since I want per-library numbers, I would need to reconstruct that information afterwards...
On 5 Dec 2018, at 10:04, Didier Verna wrote:
"Robert Goldman" rpgoldman@sift.info écrivait:
Depending on the host lisp you are using, couldn't you wrap the calls to COMPILE-FILE and LOAD in code that times those operation?
I could, but since I want per-library numbers, I would need to reconstruct that information afterwards...
Yes, I am afraid that is correct.
This is yet another problem that comes from the fact that the build plans are linear, instead of hierarchical -- for example there's no subsequence that is identifiable as being the set of operations for a particular `module`.
Logically speaking, there's a tree structure in the build process that is what you need, but I don't believe that there are any facilities in ASDF to recover that tree structure.
This may be the best you can do.
R
"Robert Goldman" rpgoldman@sift.info écrivait:
This is yet another problem that comes from the fact that the build plans are linear, instead of hierarchical -- for example there's no subsequence that is identifiable as being the set of operations for a particular module.
Logically speaking, there's a tree structure in the build process that is what you need, but I don't believe that there are any facilities in ASDF to recover that tree structure.
This may be the best you can do.
I think I'll go with Faré's suggestion, scripting it for every library and changing the cache directory every time.
On Wed, Dec 5, 2018 at 11:51 AM Didier Verna didier@lrde.epita.fr wrote:
"Robert Goldman" rpgoldman@sift.info écrivait:
This is yet another problem that comes from the fact that the build plans are linear, instead of hierarchical -- for example there's no subsequence that is identifiable as being the set of operations for a particular module.
Logically speaking, there's a tree structure in the build process that is what you need, but I don't believe that there are any facilities in ASDF to recover that tree structure.
This may be the best you can do.
I think I'll go with Faré's suggestion, scripting it for every library and changing the cache directory every time.
Of course, even my suggestion won't work so well when a system has its own secondary systems as its dependencies, when there are package-inferred-system's, etc.
For more precise timing, you could try to time things in a defmethod perform :around; however, you would still get "interesting" results for the define-op of systems that have defsystem-depends-on dependencies and other multi-stage dependencies. Also, you'd fail to account for the time outside of perform operations—which should usually be negligible, except for the quite expensive initialization of the source-registry.
In the end, timing the load* and compile-file* methods or the underlying load and compile-file functions, as suggested by Robert, might be your best bet.
Good luck,
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Democracy is but government of the busy, by the bully, for the bossy. — Arthur Seldon, "The Dilemma of Democracy"
-
Didier Verna -
Faré -
Robert Goldman