Scryer-prolog: --version takes too much time

Created on 5 Aug 2020  路  8Comments  路  Source: mthom/scryer-prolog

That is 11s in the --release version and 2m56s in the debug version. (I have a very slow machine, but still..)

strace -f -e open only shows that .scryerrc is opened (why?) and that the time is spent thereafter.

Most helpful comment

I agree with @srenatus: The package fetches the version at compilation time, so I think it is likely that other parts are the culprit. If reading ~/.scryerrc is that slow, I think that is a problem in itself, because it will also affect invocations that do not involve the --version flag. If that is really slow, then it should be improved instead of avoided.

All 8 comments

Why does that routine take so much time? We should find an alternative package.

To produce the release number, one does not need .scryerrc at all

Just my two cents here -- I may be mistaken, but the library used to figure out the version does what it does at compile time (see here), so it's basically storing a constant string in the binary you end up using. Retrieving that constant string should take negligble time.

To produce the release number, one does not need .scryerrc at all

In principle, I believe you're right. However, the way this works right now is that the toplevel prolog code decides how to deal with the argv (which contains --version), and uses said constant to output that constant string. In my opinion, that is the right way to do this -- doing as much as can be done in Prolog (instead of the Rust part of the program) seems like a good thing to me. As a side-effect, this means we'll read .scryerrc for producing the --version output. I think this is acceptible. I take it that you're not sharing my opinion, though, am I right? 馃槂

...of course I could imagine a system where the prolog toplevel also decides whether or not .scryerrc is to be read in. I don't know how feasible and desirable that is right now, though.

I agree with @srenatus: The package fetches the version at compilation time, so I think it is likely that other parts are the culprit. If reading ~/.scryerrc is that slow, I think that is a problem in itself, because it will also affect invocations that do not involve the --version flag. If that is really slow, then it should be improved instead of avoided.

I would not mind getting the version/release number by other means. As a banner, e.g.. I only need it in reproducible transcripts.

You can get the version with '$scryer_prolog_version'/1:

v(V) :- '$scryer_prolog_version'(V).

Sample query:

?- v(V).
   V = "v0.8.123-147-gbda7c ...".

The predicate v/1 is necessary in this case because $... predicates cannot be called directly on the toplevel.

Ideally, if the --version switch is used, .scryerrc should not be loaded at all. I'm addressing slow module load times in the current agenda item.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

triska picture triska  路  3Comments

dcnorris picture dcnorris  路  3Comments

notoria picture notoria  路  3Comments

XVilka picture XVilka  路  3Comments

notoria picture notoria  路  4Comments