2010-03-29 17:21:42, Alexander Wagner: > > Now it seems the cache content is lost when one forgets to set it. > > As we already have the option to set cache size, I suggest to just drop > > the option and always save cache (letting user to set a very small cache > > if he is concerned about disk space). > ... the point is IMHO not that much the amount of disk space, I think > this is a "non-issue" these days, but the actual time it takes to write > out the cache to the disk. Given a larger base (about the size of a > usual reference base) this takes some time, indeed. How much time is it?
> I admit that this is > the reason why I actually switched off the autosave function an instead > placed a quite extensive indexing scheme to Scid once I update those > bases. I might add that my reference bases don't even live on a network, > but on a not too bad local drive. What do you mean by extensive indexing scheme? Pre-generated cache? > > One idea is to store ply number of the last non-unique position in each > > game. But, this will require quite expensive indexing when database is > > modified. > I think the major issue is that you can come back to a well known > position by transpositon. Therefore, it can well be that no really good > solution exists here, especially not a perfect one. That why you would need to search a whole game, making the process quite slow. -- Michał Rudolf ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
