[Openmcl-devel] Package-local nicknames

[Gary Byers]

A few years ago we were profiling a large application developed by a
customer and we were surprised to find that a significant percentage
of the application's total execution time was spent in FIND-PACKAGE.
(I don't remember what the number was exactly, but whatever it was it
was high enough that it could be called "significant".)  When we
looked at it a bit further, we saw that many of the calls to
FIND-PACKAGE that were showing up in the profiler's output involved a
constant package name (e.g., (FIND-PACKAGE "FOO"), not (FIND-PACKAGE
x)).  Some of this came from the handling of the ~/ directive in
FORMAT, but IIRC there were a surprisingly large number of other
cases.  We decided to add some complexity to the code that
adds/deletes/changes package names so that (FIND-PACKAGE
"constant-string") could have constant cost (even if package names
change), and the customer's application sped up by some small but
significant amount.  That application may have been a bit atypical,
but it's reasonable to assume that other CL implementations may do
similar things.

An optimization like this (whether it's worthwhile or not) rests on the
assumption that the mapping between package names and packages is global,
and an extension called "package-local nicknames" sounds like it would
violate that assumption.  I have no idea whether or not this apparent
conflict could be resolved or what the issues/tradeoffs would be; I'm
merely trying to agree with people who've said "there may be some subtle
issues here."

On Wed, 6 Feb 2013, Hans H?ner wrote:

> I started writing up something that I intended to evolve into a CDR:
> ?http://paste.lisp.org/display/133561
> There were some valid concerns and when looking at the CCL code, I found the
> code sufficiently complex to make implementing such a proposal harder than I
> had hoped for.
> 
> I think that some cross-platform mechanism for local nicknames is needed,
> but I'm not sure whether the hook based package name resolution proposal is
> really better than an extended defpackage now. ?It would make sense to have
> something that implementors would actually (be able to) adopt.
> 
> -Hans
> 
> 
> On Wed, Feb 6, 2013 at 6:39 PM, Tim Bradshaw <tfb at tfeb.org> wrote:
>       On 6 Feb 2013, at 15:39, Robert Goldman wrote:
>
>       > I like the idea of a general mechanism, but I don't think this
>       hook
>       > variable will meet the ticket.
>       >
>       > What happens when there are two libraries that set
>       *FIND-PACKAGE-HOOK*?
> 
> Then they need to get together and either provide an extensible
> mechanism built on this (ie make the hook function do some kind of
> "method combination"), or at least detect that some other library has
> already hooked lookup: it's not very hard to imagine a library which
> checks for that, and if it is, calls the existing hook either before
> or after its own. ?A library which did not at least *detect* an
> existing binding would be remiss. ?Given that we can't possibly know
> if two libraries which might want to hook package lookup are in any
> way compatible, and that they often will not be, then specifying some
> (presumably complicated) mechanism by which they can cooperate seems
> inappropriate for an implementation.
> 
> >
> > We need something that will use contextual information, and that can
> > merge settings from different contexts.
> 
> My whole point was not to do that, because that is complicated,
> especially as we have no idea of what this contextual information
> actually *is*, but instead to provide a minimal mechanism, on which CL
> implementations can agree, and on which such a thing can be built:
> that's what this is. ?Using it you can both easily provide
> package-local nicknames (as I have done), or do any number of other
> things that people might want.
> 
> >
> > Any extension proposal would have to be better than
> > package-local-nicknames, IMO, in order to be acceptable.
> 
> I think you are confused about levels: this is not competing with
> package-local nicknames, it is allowing package-local nicknames to be
> implemented portably.
> 
> To respond to another message: unless implementation-hackers is it (do
> any of the CCL implementors read it?) I am not aware of another forum
> outside CLL, which I no longer read.
> 
> --tim
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
> 
> 
> 
>