Re: [sweep-devel] memory use and need

[Conrad P. <co...@ve...>]

Hi Heimo,

some interesting observations here, esp. that the jump from 384 to 512 MB
didn't provide much performance improvement. I'm not sure why that would
happen.

Sweep currently holds too much in RAM -- as well as the sample data, it's
caching undo buffers, which could easily go to disk without affecting
interactivity. I plan to make this change when I get back from linux.conf.au,
ie. in February. (Currently working on much-needed user documentation!)

So, expect performance to improve in that area over the next few months.
The plan (for 1.0) is for only live sample data to be in RAM, and everything
else on disk, ie. memory usage only bounded by the size of the files and not
affected by edits. After 1.0, some more aggressive disk caching ;)

Perhaps someone with more systems tuning knowledge can help you tune your
memory for the time being?

Conrad.

On Wed, Jan 08, 2003 at 12:42:39AM +0000, Heimo Claasen wrote:
> A question to whoever is knowledgeable:
> How does Sweep use memory, and how much does it need ?
> And does it use/need (a how large) swap (partition/file) ?
> 
> Background: an earlier remark from Conrad that Sweep holds evferything
> loaded in mem, and thus is limited to what there is in living (RAM) mem.
> 
> History: i stepwise upgraded th machine from 192 --> 320 --> 384 --> 512
> MB (step two included a change of MoBo) and finally found the right
> chips to get the present Mobo to its full capacity of 768 MB; swap
> partitions were rather static, around 360 MB.
> The observations were blurred further by (a.) upgrading of the
> "systems" (Mandrake 7.2 to 8.2, and Debian "potato" to "Woody"
> respectively, on exchageable HDs) and (b.) the constant upgradings of
> Sweep's versions themselves.
> 
> Empirical: I noticed a remarkable improvement - i.e., capacity of
> holding a larger number of clips (usually between 3 to 5 min length)
> loaded - only with the change from step 1 (192 MB RAM) to step 2 (320 MB
> RAM). Especially the result with the hitherto last step (384 to 512 MB
> RAM) was disappointing: definitely no discernable improvement, with
> about ten to a dozen of the test-clips loaded, the GUI gets extremely
> slow, with 14 to 16 of the clips it stalls almost completely - at
> that point, any editing in/between Sweep windows is practically
> impossible.
> 
> The MoBo has three mem banks which now hold 1 x 256 MB and 2 x 128 MB
> mem bars. Further upgrading of the latter to the type of the former
> (for which I finally found the good sort) is a bit expensive but would
> result in the 768 MB max. capacity of this Mobo.
> 
> Only that I got somewhat sceptical by now if this would really result in
> a corresponding performance increase for working with Sweep.
> 
> I would like to get some more insight into this side of Sweep's
> behaviour in order (a) to decide on the further hardware (RAM)
> upgrade, and (b) on perhaps necessary system re-arrangements (swap
> volume ? by file or by partition ? X window managers ?)
> 
> ("Work" consists almost exclusively of editing/montage of speech; though
> the intention is to work on _long_ pieces of between 15 and 60
> minutes each, with much shoveling around and pasting of bits and
> piecess - even for a smaller sound feature, this goes up quite
> quickly to much more than a dozen of clips to handle.)
> 
> // Heimo Claasen // <hammer at revobild dot net> // Brussels 2003-01-07
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> sweep-devel mailing list
> swe...@li...
> https://lists.sourceforge.net/lists/listinfo/sweep-devel