Re: Slow application startup when using a theme

[Fred Kiefer]

On 09.01.2012 20:59, Eric Wasylishen wrote:
> > 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.

I am not completely sure why this code is that way. What I remember is
that we need to override all the already loaded images.
But there was more to it. It could have to do with unloading an image
and restoring the previous image state.
I hate the way we deal with images in themes and have often stated this,
but haven't come up with a better idea up to now.

> 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.

This is correct and it is what I already stated. My suggestion here was
to rewrite imageNamed: to first check the unfiltered images and only
later the filtered ones.

> How about adding caching to NSBundle? It already caches the budle
> info.plist, why not the directory listing of the resource directory?

Here the question is what should we cache?

> Also, it might be nice if NSBundle would have a private method:
> -(NSArray*)pathsForResource: (NSString*)name ofTypes:
> (NSArray*)types;

Yes, this is exactly the method we should be using. That way we could 
also resolve the problem of inconsistent localisation, that is the case 
where we have localisation files with different extensions and for some 
cases fall back to the non localised versions, because they get found first.

> 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 great, I am just wondering how Apple gets by without this method?