gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Slow application startup when using a theme


From: Eric Wasylishen
Subject: Re: Slow application startup when using a theme
Date: Mon, 9 Jan 2012 12:59:20 -0700

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.


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.

Eric





reply via email to

[Prev in Thread] Current Thread [Next in Thread]