Re: Slow application startup when using a theme

[Philippe Roussel]

Le lundi 09 janvier 2012 à 12:59 -0700, Eric Wasylishen a écrit :
> Hi,
> Thanks for the report, Philippe; this is indeed a fairly serious problem. :-(
> 
> > 
> > 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 ?
> 
> That sounds like a good idea.
> 
> Much of the overhead when using Neos is caused by the section of
> -[GSTheme activate] which loads all images in the theme.
> 
> Here are some tests:
> startup Ink with default theme: 51k syscalls
> startup Ink with Neos.theme: 183k syscalls
> startup Ink with Neos.theme, with GSTheme.m lines 473 to 539 commented
> out: 95k syscalls.

This code isn't working correctly then as it's supposed to load the
bundle images and cache them so that [NSImage +imageNamed:] can find
them quickly.
It should minimize the work to load all bitmap as it's using the list of
existing files, something close to what I proposed, instead of trying
every paths on the planet...

Or am I missing something here ?

> Fred, even if we implement image filter services support and move the
> ImageMagick support to a service, +[NSImage imageNamed:] would still
> do just as much work because it uses [NSImage imageFileTypes], which
> would include the types supported by filter services.
> 
> 
> How about adding caching to NSBundle? It already caches the budle
> info.plist, why not the directory listing of the resource directory?
> 
> Also, it might be nice if NSBundle would have a private method:
> -(NSArray*)pathsForResource: (NSString*)name ofTypes: (NSArray*)types;
> 
> which given a name like @"common_ArrowRight" and a types array
> (@"tiff", @"png", … )
> would return an array of paths to any matching resources in the
> bundle, and it would do so efficiently using a cache of the directory
> contents.

Sounds nice.

Philippe