Re: Slow application startup when using a theme

[Eric Wasylishen]

Hi Fred,

On 2012-01-09, at 2:26 PM, Fred Kiefer wrote:

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

I didn't like the current approach either…  I just committed a rewrite of how 
theme images are handled which gets rid of theme proxies entirely, and 
eliminates the code in -[GSTheme activate] and -[GSTheme deactivate] which were 
setting/restoring images.

Now, when a name is set on an NSImage instance, it also subscribes to the theme 
change notification. When an NSImage receives this notification, it does the 
name-to-path lookup again that +[NSImage imageNamed:] did, and reloads itself 
(discarding all reps) if the path has changed.

It's a fairly major change but I tested Gorm, GSTest, SimpleAgenda, and tried 
switching between the GNUstep default theme, Neos, and Etoile's Nesedah theme 
while the apps were running, and all images seemed to update properly.

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

Ah, I agree that sounds like a good idea.

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

I'm not sure. The preliminary caching Richard just added makes a big difference 
as I reported (95% reduction in system calls, when using Neos.theme and the 
ImageMagick image rep is installed.)

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

Ok, great. I'm not going to attempt this right now but it would be nice to do 
at some point.

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

Not sure, perhaps they use a private method as well.

Regards,

Eric