On Sun, 13 Feb 2005 11:08:10 +0100 David Ayers <[EMAIL PROTECTED]> wrote:
>| Manuel Guesdon wrote: >| >| > I've commited some changes. Part of this is optimizations. >| > I've experimented a >30% gain in speed for fetching 3000 >| > records. >| >| This sounds great! >| >| > I've added EOPriv.[hm] which handle some catching and >| > initializations things. May be it's not the best idea to put all this >| > here and suggestions/changes are welcome. >| >| Actually I already have EOPrivate.[hm] locally :-) I'll merge them soon. >| But I admit I would have prefered to keep the static caches local to >| the files in which they were used. Some of them are in teir files (EOEditingContext, EODatabaseContext). I've put others in the same place to have a simple and common initialisation place so we can be sure that nothing is used before being initialized but it's not necessary the best solution. >| But I'll try to work with the new >| version a bit. I'm also not really comfortable with all the IMP >| caching. Are you sure that's a susbstantial amount of the 30%? Yes, on fetching 3 000 records and I have another set of optimizations which should improve that :-) I've manly worked on very often used methods and more specifically in loops in them. >| > I've temporary reverted David Ayers's changes in >| > EOAttribute -adaptorValueByConvertingAttributeValue because we can >| > have a NSString to to store in a NSNumber class attribute >| >| Storing an NSString in something that's declared as NSNumber seems wrong >| and I vagely rember testing it quite a bit. Maybe we need some type of >| formatter here though. I'll go back and look at this, as I may be >| missing something. I think it's common as you often get user input (for date, number,...) as string I haven't investigate deeper on this (lack of time) but we should find a way to well handle this. >| > I have a problem with EOEditingContext -_objectBasedChangeInfoForGIDInfo: >| > "Assertion failed in EOEditingContext(instance), method >_objectBasedChangeInfoForGIDInfo:. called with GID >| > <EOKeyGlobalID 0x82d4d50 - Entity SessionArchive - keysValues:"883878" >(NSIntNumber) > not managed by receiver >| (0x9c41be8) >| > >| > The gid was recorded in EditingContext 0x9f12fd8 and this message come >| > from 0x9c41be8 editing context. >| > >| > David, any idea ? >| > BTW, may be you can double check my changes in EOEditingContext to be >sure I haven't break yours as the merge was >| a >| > little complex :-) >| >| Indeed, that assertion was there for testcases that it seems I haven't >| finished yet. You can remove it for for now and I'll have a closer look. OK. >| > Except -_objectBasedChangeInfoForGIDInfo: problem, it seems to work >| > but I didn't make deep tests. I'll do it as soon as I can. >| > >| >| I'm fighting a flu right now, but should be able to resolve these issues >| in the next few days. Great ! Thx. Manuel _______________________________________________ Gnustep-dev mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/gnustep-dev
