[asdf-devel] Faster loading for deployed systems?

[Robert Goldman]

On 4/22/12 Apr 22 -3:47 PM, Faré wrote:
> Dear Erik,
> 

>> ASDF assumes that since the system def file has not changed, the system
>> hasn't been changed either (I know there has been discussion of this
>> assumption.) But lets assume that at least part of the reason for that is
>> because it is very time consuming to check the entire set of files every
>> time the developer wants to recompile and load just a single file.
>>
> I don't think that's true, but my head hurts just thinking about it.

This is not an accurate understanding.  It has come up over and over.
The right thing to do would be to check systems recursively, but there
are a number of reasons why this does not work with the current state of
ASDF.  You can look in the archives for explanations; it has been
discussed many times [I am not trying to be rude; I just don't have the
energy to write up another copy of the explanation.  Probably we should
put it in as a FAQ in the manual...]
> 
>> Why not assume in a deployment mode that NO system will have changed if it
>> is already loaded in memory, and unless the application has asked that it be
>> reloaded? This would be for performance as well as for safety -- we really
>> don't want dependency checking to result in any filesystem checks, etc.
>>
> Because that's wrong? I don't have as many dependencies as you do when
> I reload a system with asdf, but usually, I do want the dependencies
> to be reloaded.

The deployment mode is an edge case and can already be handled very
efficiently by dumping an image with the (stable) system you want
already loaded (cf. Xach's buildapp, although I know that's for SBCL,
rather than CCL; and CCL:SAVE-APPLICATION --
http://ccl.clozure.com/manual/chapter4.9.html#Saving-Applications).  In
some sense you are right, ASDF is slow for this use case, but it's
really not the use case ASDF is looking for.

And ASDF is already too liberal about assuming stability, in a way that
breaks a lot of people's development practice (see my earlier remarks);
the last thing I would want to do is make it even more likely to miss a
change and build an inconsistent system.

Best,
r