Re: Slow application startup when using a theme

[Philippe Roussel]

Le lundi 09 janvier 2012 à 16:47 +0100, Fred Kiefer a écrit :
> On 09.01.2012 15:00, Philippe Roussel wrote:
> > Le lundi 09 janvier 2012 à 14:17 +0100, Fred Kiefer a écrit :
> >> On 09.01.2012 00:58, Philippe Roussel wrote:
> >>> Hi,
> >>>
> >>> I just noticed that applications start a lot slower when using a non
> >>> default theme like Neos.
> >>>
> >>> To test this I added a NSLog as the first line of the AppController
> >>> -init method and this is what I get (with a hacky method).
> >>>
> >>> With GNUstep theme :
> >>>
> >>> philou@woody:~/sources/SimpleAgenda$ date +%X.%N&&   
> >>> ./SimpleAgenda.app/SimpleAgenda
> >>> 22:56:17.054406845
> >>> 2012-01-08 22:56:17.826 SimpleAgenda[14542] AppController -init
> >>>
> >>> With Neos theme :
> >>>
> >>> philou@woody:~/sources/SimpleAgenda$ date +%X.%N&&   
> >>> ./SimpleAgenda.app/SimpleAgenda
> >>> 23:01:01.740665917
> >>> 2012-01-08 23:01:05.015 SimpleAgenda[14643] AppController -init
> >>>
> >>> This is almost 3 seconds slower and easily reproducible :(
> >>>
> >>> When I apply the following patch, application startup is under 0.5
> >>> second, no matter what theme I choose.
> >>>
> >>> --- Source/NSImage.m      (révision 34462)
> >>> +++ Source/NSImage.m      (copie de travail)
> >>> @@ -1812,6 +1812,7 @@
> >>>
> >>>    + (NSArray *) imageFileTypes
> >>>    {
> >>> +  return [NSArray arrayWithObjects:@"tif", @"tiff", @"png", @"gif",
> >>> @"jpeg", @"jpg", nil];
> >>>      return iterate_reps_for_types([NSImageRep registeredImageRepClasses],
> >>>                                    @selector(imageFileTypes));
> >>>    }
> >>
> >> Hard coding the file types isn't an option her, what we could do is
> >> cache the file types in the four relevant methods and make sure we clear
> >> up the cache each time a new NSImageRep subclass gets added or removed.
> >> I will try to implement that and you should then measure the time
> >> difference.
> >
> > Fred, I know hard coding is not a solution, this was just a simple way
> > to reduce the number of file types. Caching will not improve speed (I
> > tried it after my email), the problem comes from the code in NSImage
> > +imageNamed and the number of file types. Look at the attached file in
> > my previous mail, you will see that +imageNamed is looking for the file
> > at hundreds of places (number of paths * number of file types).
> 
> Thank you for the explanation, now I understand the issue. It is the 
> GSImageMagickImageRep class that is causing the trouble. It offers 
> almost 200 hundred image formats and that makes image lookup very slow. 
> The real solution here would be to turn this class into a conversion 
> filter and rewrite the image lookup to first check for unfiltered image 
> types and only later for the filtered ones.

That would probably works but what about changing how +imageNamed:
works ?

When this method is called with a image name lacking an extension (ie
'GNUstep' or 'common_arrowLeft'), it tries to find a existing file by
adding any know extension and calling a NSFileManager method, and this 3
times (main bundle, theme bundle and then every Images directory in the
system). With bitmaps existing only in the system directories this is
extremely costly as it tries something like 500 paths before the good
one. (And I know you understand all that, I'm just filling the blanks
for the others who might be interested, sorry :o)

Couldn't we inverse the thing and check if one of the existing file in
the directories has an extension known to be an image type ? I mean :
list the files in the main bundle, look for the ones with a matching
name (ie 'common_arrowLeft') and then check if the extension is none.
The list of file in a bundle could also be cached.

Worth trying ?

Philippe