[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Slow application startup when using a theme
From: |
Richard Frith-Macdonald |
Subject: |
Re: Slow application startup when using a theme |
Date: |
Mon, 9 Jan 2012 20:51:12 +0000 |
On 9 Jan 2012, at 19:59, Eric Wasylishen wrote:
> 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?
I hacked in some quick/dirty cacheing in NSBundle. Does it make enough
difference to be worth doing properly rather than reverting?