Re: [Scid-users] Fast tree

2008-04-25 Thread Michal Rudolf
Alexander Wagner, piątek, 25 kwietnia 2008: >Additionally, as it comes to sorting you'll have the memory >footprint Pascal mentioned, that is just the sorting will >take several hours on such a DB if you did not know about >adding another GB of real RAM first. I don't really see any memory footp

Re: [Scid-users] Fast tree

2008-04-25 Thread Alexander Wagner
Michal Rudolf wrote: Hi! >>> So, best idea (though breaking some compatibility) will >>> be to always sort games by ECO (so that same position >>> appears in a single block) and store user's sorting >>> order separately. >> IMHO this is not a good idea, simply cause this results >> in the f

Re: [Scid-users] Fast tree

2008-04-25 Thread Alexander Wagner
Michal Rudolf wrote: Hi! >> But by sorting the games by ECO code, the probability is >> very high that the games will be gathered in some way, >> hence the dramatic speedup. Note that with a base not too >> big (1M games) and 2 GB RAM this sort phase may be >> useless. > So, best idea (thou

Re: [Scid-users] Fast tree

2008-04-25 Thread Michal Rudolf
Alexander Wagner, piątek, 25 kwietnia 2008: > > So, best idea (though breaking some compatibility) will be > > to always sort games by ECO (so that same position appears > > in a single block) and store user's sorting order > > separately. >IMHO this is not a good idea, simply cause this results

Re: [Scid-users] Fast tree

2008-04-24 Thread pgeorges
Michal Rudolf a écrit : > pgeorges, czwartek, 24 kwietnia 2008: > > >> Scid loads games by blocks, of 32 kB each which corresponds to 300-400 >> games. So if you want to fill the filter for 1 games that are spead >> each in a different block because the base is unsorted, you will load >> 32

Re: [Scid-users] Fast tree

2008-04-24 Thread Michal Rudolf
pgeorges, czwartek, 24 kwietnia 2008: >Scid loads games by blocks, of 32 kB each which corresponds to 300-400 >games. So if you want to fill the filter for 1 games that are spead >each in a different block because the base is unsorted, you will load >320 MB ! And this takes time, unless every

Re: [Scid-users] Fast tree

2008-04-24 Thread pgeorges
Michal Rudolf a écrit : > Pascal Georges, środa, 23 kwietnia 2008: > > >> The code works in this way : the list of games found (call it LG) in the >> cache for the last time is kept as a basis to speed up further searches. For >> example 2 games for a base of 3M. If the game was not in LG w

Re: [Scid-users] Fast tree

2008-04-24 Thread Michal Rudolf
Pascal Georges, środa, 23 kwietnia 2008: >The code works in this way : the list of games found (call it LG) in the >cache for the last time is kept as a basis to speed up further searches. For >example 2 games for a base of 3M. If the game was not in LG when >scanning all 3M, I simply bail ou

Re: [Scid-users] Fast tree

2008-04-23 Thread Pascal Georges
2008/4/23 Michal Rudolf <[EMAIL PROTECTED]>: > Pascal Georges, środa, 23 kwietnia 2008: > >Hi, > > > >I commited some code in CVS where Tree window refresh is 20 times faster > >(sometimes more !). > Can you please remember CVS link? cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/scid2 login cvs -z

Re: [Scid-users] Fast tree

2008-04-23 Thread Pascal Georges
2008/4/23 Alexander Wagner <[EMAIL PROTECTED]>: > By "Index" I did not necessarily refer to the existing index > but also included the option to add a completely new index > file probably containing the ECO sorting for easy access and > to speed up things on that basis. (Its just that I do some >

Re: [Scid-users] Fast tree

2008-04-23 Thread Alexander Wagner
Pascal Georges wrote: Hi! > Hm, the feature is nice ineed though _sorting_ the DB > by Eco code (or whatever) is problematic. Isn't that > be implemeted better on a properly sorted index? > Resorting large DBs, especially RefDBs is IMHO > something to avoid. > > Index i

Re: [Scid-users] Fast tree

2008-04-23 Thread Pascal Georges
2008/4/23 Alexander Wagner <[EMAIL PROTECTED]>: > Michal Rudolf wrote: > > >> Here is the changelog : > >> - added an option menu for Tree windows : Fast Mode. This will > dramatically > >> reduce the time needed to refresh the tree window but will not > handl

Re: [Scid-users] Fast tree

2008-04-23 Thread Alexander Wagner
Michal Rudolf wrote: Hi! >> Hi, >> >> I commited some code in CVS where Tree window refresh is 20 times faster >> (sometimes more !). > Can you please remember CVS link? scid2.cvs.sourceforge.net >> Here is the changelog : >> - added an option menu for Tree windows : Fast Mode. This will

[Scid-users] Fast tree

2008-04-23 Thread Pascal Georges
Hi, There are now 3 modes for Tree window (see the options menu): - slow mode (the classical one); - fast mode (will work on a limited number of games after the last cache hit, but will miss *some* transpositions); - fast and slow mode : the tree is refreshed nearly instantly, and several seconds

Re: [Scid-users] Fast tree

2008-04-22 Thread Michal Rudolf
Pascal Georges, środa, 23 kwietnia 2008: >Hi, > >I commited some code in CVS where Tree window refresh is 20 times faster >(sometimes more !). Can you please remember CVS link? >Here is the changelog : >- added an option menu for Tree windows : Fast Mode. This will dramatically >reduce the time n

[Scid-users] Fast tree

2008-04-22 Thread Pascal Georges
Hi, I commited some code in CVS where Tree window refresh is 20 times faster (sometimes more !). Here is the changelog : - added an option menu for Tree windows : Fast Mode. This will dramatically reduce the time needed to refresh the tree window but will not handle some move transpositions. It i