Alexander Wagner wrote: > Joost 't Hart wrote: >> Pascal Georges wrote: > > Hi! > >>> Did you tell us how much RAM do you have (total / free) ? >>> File cache is really important with Scid (and other >>> intensive apps). >> >> Thanks Pascal. No, I did not, although Alexander hinted >> towards it. >> >> I have 1 GB of RAM, and indeed this is probably not >> sufficient to run the compaction on a dbase of this size. > > Ah. Ok, here I'm at a bit more, and I noticed that breaking > the GB barrier gave quite a jump in my case.
I´ll go shopping tomorrow... sure enough. > >> Upon opening this base, scid eats already about 350 MB. >> Which is a lot, but not a problem per se. > > Well, the indicees have to live somewhere... Yep, but this is too big a bed even for them (160 MB should suffice). > >> What I realized only later, is that gamefile compaction >> after a serious re-sort comes with a serious amount of >> seek operations in the old game file. > > Sure, as it has to collect the game blocks and write it > block by block. This should be almost similar to a defrag if > you remember those old DOS days... (Actually, IMHO this is a > point why it should never be necessary to really sort the > database, but only the view.) Hm, yes, tend to agree, but it is contradictory to notes in the help file. My base happened to be organised chronologically and I wanted to optimise for tree usage... And, BTW, some testing at hand as well :-) > >> The OS wants to try to accomodate this - indeed by caching. > > Ok. Solved... :( > >> However, caching of a 400 MB file on my system, apart from >> scid taking its bite, is not trivial. > > Most likely it's the killing part... > >> I saw immediate improvements after closing any other >> application. With a cheap desktop like wmaker there was >> even more improvement. > > <scnr> > :) Don't call WindowMaker cheap! Its one of the greatest > things for a Desktop! > > It just uses only a tiny amount of RAM for giving more > features and performance than others. In earlier days > this was called "efficient". Today, it is called > "uncool", for whatever reason. > </scnr> Agree (what is your scnr tag supposed to disclaim ;-) ) but it _is_ something to get used to after some nifty gnome/kde experience. > >> Nevertheless, in the end, the performance remains >> disappointing. >> >> One final question from this end: Is eating the 350 MB really required? > > I fear, that droping the indices would be even worse, not? Yep, but see above. > >> Could´nt we release a lot of this while compacting? Or is there no >> way to do this currently... I see that this memory is not even >> released after I do completely close the data base. > > This sounds a bit strange, however. I am still working on my memory prober (there´s many new/delete´s in there...). Apparently Pascal has the experience the proc data cannot be relied upon, which is what I did indeed. > > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
