[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-developer
Subject:    Re: [gimp-devel] hungry for memory...
From:       Marc Lehmann <pcg () goof ! com>
Date:       1998-09-20 11:52:24
[Download RAW message or body]

On Fri, Sep 18, 1998 at 12:01:10PM +0200, Benedikt Eric Heinen wrote:
> 
>   I used a slide scanner to scan a photo slide - the resolution of the slide
> was 3888x2592 color scan, and xscanimage said, the picture would be 28.8MB
> in size. After I saved it, I quit the gimp temporarily. Later I started the
> gimp and loaded the gimp -- according to top -- used ~49MB of memory.

One should take undo buffers and the like into account. But it might well
be possible that there is a problem in Gimp.

>   Can this be true, can the unsharp mask of a 29MB picture really use up
> 376MB (without counting the program and the picture, which was already
> loaded at the beginning of the unsharp mask function, when the gimp only
> used 49MB)?

It shouldn't, but see below.

> To add up to this "strangeness":
> 
>   -> Closing the unsharp masked picture after saving it made the gimp 
>      go down to only use 78881 KB swap file, with the main memory size
>      being unchanged.

The swap file can only made smaller if deallocations are at its end.
Otherwiese you would need to reshuffle the data from the end to the
beginning, and that wouldn't help the performance.

Wether the main memory size shrinks or not depends entirely on your os -
most unixen won't free any RSS space after an application has allocated it.
Newer Linuxen do, but not in all cases.

> function takes as toll, but -- is this memory consumption here something 
> NORMAL for this kind of operation?

The problem is that most of the swap file as well as most of the main memory
might be "free" space, so RSS+swap file size is no indication of memory use
(not even peak memory use).

OTOH, maybe the memory (swapfile) management of the gimp could be smarter,
but I suspect it was written for speed, not for space effectiveness (and
shuffling data around on the disk is a very big price)

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |

[prev in list] [next in list] [prev in thread] [next in thread]