Re: [isabelle] Lazy Messages (Was: Unicode (Was: Update on I3P))
- To: Joachim Breitner <mail at joachim-breitner.de>
- Subject: Re: [isabelle] Lazy Messages (Was: Unicode (Was: Update on I3P))
- From: Holger Gast <gast at informatik.uni-tuebingen.de>
- Date: Mon, 11 Oct 2010 14:46:24 +0200
- Cc: isabelle-users at cl.cam.ac.uk
- In-reply-to: <1285059024.9562.10.camel@kirk>
- References: <4C262D4C.firstname.lastname@example.org> <1279399902.2461.125.camel@kirk> <4C459EB4.email@example.com> <1284126876.3494.14.camel@kirk> <1284127736.3494.17.camel@kirk> <alpine.LNX.firstname.lastname@example.org> <1284816664.14778.3.camel@kirk> <4C9748FB.email@example.com> <1285059024.9562.10.camel@kirk>
- User-agent: Thunderbird 220.127.116.11 (X11/20100411)
> I have another issue with i3p to report that is more severe. In my
> current project, I sometimes get quite large goals. When that happens,
> i3p becomes very slow when I move backwards and forwards in my theory.
> My ProofGeneral using colleges do not have this problem.
The issue arises from I3P trying to have the messages of previous
commands available for the user for inspection. For this to work,
Isabelle has to print the goal state, which may take some time
(sometimes > 100ms, or even more for really large goal states).
I had already noticed this, but it was never severe enough to prompt action.
Since we agreed that the availability of previous messages is desirable,
simply turning off the output is no solution.
I have therefore added to the I3P framework the notion of
"lazy messages", of which Isabelle only sends a "proxy" with an identifier,
and internally keeps the information for generating the message
on request. (Due to the structure-sharing, purely functional
representation employed throughout Isabelle, this is not a
major overhead.) When the user points the UI to a lazy message,
it is requested from Isabelle on the fly.
With this setup, the perceived processing speed in
release 1.0.8 has increased very much.
Lazy messages, as implemented, also cover more general scenarios
than just the goal output. For instance, I have had good results
for bulk trace messages where the proxy contained enough information
to let the user decided whether the message is relevant at all.
If this is interesting to other people, I can provide more details.
Also, the LazyMessageHandler in the Isabelle2009Driver
(in the 1.0.8 source code) explains the essential idea of how to
garbage-collect message references across the process boundary
using Java's WeakReference/ReferenceQueue mechanisms.
Thank you very much for pointing this out, and also for the offline
discussion and for testing the changes beforehand. It certainly
raised very interesting design & programming challenges :)
This archive was generated by a fusion of
Pipermail (Mailman edition) and