Leo Butler <l_butler at users.sourceforge.net> writes:
> Content-Type: multipart/mixed;
> boundary="===============2895714127666894247=="
>
> --===============2895714127666894247==
> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1;
> protocol="application/pgp-signature"
>
> --=-=-=
> Content-Type: text/plain
^^ Huh?
>
> What I would suggest is to dump the info hash for each lisp you are
> building with and use read-time conditionals to load the right one
> into a Maxima session. Even with 4-5 lisps, this will still be faster
> than the perl script, and you will get the right offsets for each lisp.
If possible, it would be nice not to do this. I mean, my main incentive
for working on the way we load the info files was to make sure it was
absolutely impossible for things to get out of sync.
> Although you may think everyone is running fast hardware, Maxima is
> being ported to run on low-spec hardware like phones where it may not
> be so nice to wait while Maxima regenerates an info hash that could
> have been done once at build time.
Yes. I do indeed realise that not everybody is running Maxima on a fast
computer.
Which is why I've put quite a bit of effort into checking this runs
reasonably fast. But I'll ask you the same question as I asked Ray: What
would you consider an acceptable wait, once per session, the first time
you called a documentation function?
My gut instinct is that the answer is something like 1 or 2
seconds. With the current implementation on SBCL or GCL and assuming
that time scales roughly inversely to clock speed, that corresponds to a
minimum clock speed of 570MHz. My phone is a Galaxy Ace, which I
recently bought second hand for ?50. It came out 2 years ago. It has a
clock speed of 800MHz. Yes, I know that this is ARM, not x86 and there
are probably other relevant factors, but I feel like the code I'm
talking about isn't far off acceptable performance.
Do you agree, or are we a factor of 10 of what you'd consider
acceptable?
Rupert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20130325/747cb810/attachment.pgp>;