felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Bundle cache changes
Date Mon, 11 Oct 2010 13:20:02 GMT
  On 10/11/10 2:36, Valentin Valchev wrote:
>   On 1.10.2010 г. 18:37 ч., Richard S. Hall wrote:
>> Hey everyone,
>>
>> I've made some changes to the bundle cache layout and handling to
>> improve performance and clean up code. I've tried to maintain backward
>> compatibility with old caches, but I'd appreciate is someone could try
>> it out on their caches to see if it works.
>>
>> ** Back up your caches just in case! **
>>
>> Note that the new cache format will not work with older frameworks. So
>> you cannot use a cache created with this new framework with previous
>> frameworks; however, previously created caches should mostly continue
>> to work between the two although there will be a loss of fidelity
>> since changes to state are only saved to the new way or the old way
>> depending on if you are running on the new framework or the old one.
>>
>> For the curious, I've combined five bundle cache files (id, location,
>> state, start level, last modified, and refresh count) into a single
>> file and try to avoid excessive file accesses. This appears to improve
>> startup time when you have a cache with lots of bundles, but your
>> mileage will vary based on platform and other factors. Although, you
>> won't necessarily see any improvements if you are using an old cache,
>> since it will revert to the old way.
> Hello,
> Well, maybe it will be even faster if you have only one ... let's say
> "index" file, for all bundles, that contains that internal data. This
> way, at startup you just need to load one index, and then based on it,
> to continue with bundle initialization. Just need to make sure, that
> writing to that index file is atomic and will survive sudden power fail
> or Ctrl+C.

Yeah, I'm not sure I'm willing to give up on having a simple, crash 
resistant cache that is easily editable by hand. But that time may come.

-> richard

> Yes, this means when the state of single bundle is changed, then you
> should update the master index. But I'm quite sure that the write
> performance will depend so much on the size of the written file, until
> it is less than the disk block size. As example for NTFS you have
> default cluster size 4096 - big enough for index file.
>
> Regards,
> Valentin
>
>> Thanks.
>>
>> ->  richard
>>
>>
>

Mime
View raw message