GNU bug report logs - #12463
24.2; pos-visible-in-window-p gets slower over time

Previous Next

Full log

Message #106 received at 12463 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: cyd <at> gnu.org, jwalt <at> garni.ch, 12463 <at> debbugs.gnu.org
Subject: Re: bug#12463: 24.2; pos-visible-in-window-p gets slower over time
Date: Fri, 21 Sep 2012 20:45:11 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Fri, 21 Sep 2012 19:07:28 +0200
> Cc: Chong Yidong <cyd <at> gnu.org>, jwalt <at> garni.ch, 12463 <at> debbugs.gnu.org
> 
> On Fri, Sep 21, 2012 at 7:03 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > Am I missing something, or will this really call the initialization
> > function again and again and again?  AFAIU, if an image's library is
> > already in Vlibrary_cache, and the cdr of its association is non-nil,
> > that means the initialization function was already called for the
> > corresponding image type, and it returned non-zero.  So there's no
> > need to call it again.
> 
> In fact, if an image library is already in Vlibrary_cache, and the cdr
> is nil, that also means that the initialization function was called
> for that image type, if failed, and should never be called again.

That part is OK: if the cdr of the association is nil, the
initialization function is not called.

And I see now that image_types is searched before looking in
Vlibrary_cache, so the answer to my question is "yes, I did miss
something".

IOW, Vlibrary_cache is only searched to detect a previous unsuccessful
attempt to load the library, in which case we don't try again.
Otherwise, the image type will either be found in image_types, or
loaded by calling the initialization function.  So I guess this is
okay, sorry for the noise.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.