Pascal Georges wrote:
>
>
> 2009/3/11 Joost 't Hart <[email protected]
> <mailto:[email protected]>>
>
> Pascal Georges wrote:
>
> 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.
>
>
> Also for Tree operations, 2 GB leads to far better performances than 1
> GB. I experienced some operations going down from several hours to 20
> minutes or so.
Haha! Went to the shop for another 2GB, installed xfce (4) window
manager (thanks Alexander for leading me to this wonderful stuff by
mentioning thunar - its file manager), and things are sunnier than ever.
>
>
>
> Upon opening this base, scid eats already about 350 MB. Which is a
> lot, but not a problem per se.
>
> 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. The OS wants to try to accomodate this - indeed
> by caching. However, caching of a 400 MB file on my system, apart
> from scid taking its bite, is not trivial.
>
> I saw immediate improvements after closing any other application.
> With a cheap desktop like wmaker there was even more improvement.
> Nevertheless, in the end, the performance remains disappointing.
>
> One final question from this end: Is eating the 350 MB really
> required? 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.
>
>
> Why are you sure the memory was not released ? I don't want to go into
> discussions about memory management, but process sizes are often
> meaningless.
You might be right, in that sometimes proc sizes as probed by system
monitors may never go down, but...
I did the following two experiments using two bases b1 (big) and b2
(smaller).
Numbers are virtual, memory and shared in MB's respectively.
- Start scid => {122, 36, 6}
- Open b1 => {332, 242, 6}
- Open tree b1 => {387, 297, 6}
- Close tree b1 => {387, 297, 6}
- Close b1 => {387, 297, 6}
- Open b2 => {387, 297, 6}
- Open b1 => {431, 342, 6}
- Start scid => {122, 36, 6}
- Open b2 => {176, 89, 6}
- Open b1 => {385, 295, 6}
The postconditions of the two experiments are identical (both bases
open, no tree open), yet the amount of memory used is different.
Note that the final step in both experiments increases scid´s memory
demands (so we cannot blame the monitor not noticing the memory in use
to go down at this point), and that there is no way for the system
monitor to discriminate between ´base memory´ and ´tree memory´.
What's more: My monitor roughly behaves as I would expect it to while
running the following simple program:
#include <stdlib.h>
#include <stdio.h>
int main( void )
{
char* buf;
printf( "About to alloc mem\n" );
getchar();
buf = new char[100000000];
printf( "About to free mem\n" );
getchar();
delete[] buf;
printf( "Memory freed\n" );
getchar();
return 0;
}
This program is said to use {11,0,1}, {107,0,1} and {11,0,1} MB in the
three states separated by the getchar() events.
Maybe still too early for conclusions, maybe not, yet it looks as if
- scid does free up memory for later use (b2 could be opened in
experiment 1 without extra memory demands)
- scid does not release memory freed up to the OS
- scid discriminates tree memory from non-tree database memory.
Cheers,
Joost.
------------------------------------------------------------------------------
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
