ardour:memoryleak
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
ardour:memoryleak [2008/11/08 17:16] – deva | ardour:memoryleak [2008/11/12 22:21] – deva | ||
---|---|---|---|
Line 27: | Line 27: | ||
The limiting history functionality was supposed to never make the undolist contain more that a given number of commands (and therefor delete the oldest commands when new ones are put into the list), but it seems that evens setting the limit to 1, doesn' | The limiting history functionality was supposed to never make the undolist contain more that a given number of commands (and therefor delete the oldest commands when new ones are put into the list), but it seems that evens setting the limit to 1, doesn' | ||
- | ====Test==== | + | ====Test |
My idea was then to try and delete all the objects when they were inserted into the undo list.\\ | My idea was then to try and delete all the objects when they were inserted into the undo list.\\ | ||
This was done by editing the '' | This was done by editing the '' | ||
Line 43: | Line 43: | ||
This now deletes all '' | This now deletes all '' | ||
I then tested some of my larger projects, and could conclude that my changes indeed did lower the memory allocation problem.\\ | I then tested some of my larger projects, and could conclude that my changes indeed did lower the memory allocation problem.\\ | ||
- | I guess the idea of the '' | + | I guess the idea of the '' |
Furthermore I want to point out that there are still '' | Furthermore I want to point out that there are still '' | ||
+ | |||
+ | ====Measuring==== | ||
+ | A test run of the changed code versus the unchanged code with 40 cuts on a 16 track project made the following results: | ||
+ | ^ Code ^ mem usage after load ^ mem usage after 40 cuts ^ accumulated memory usage ^ | ||
+ | | Unchanged code | 99MB | 217MB | 118MB | | ||
+ | | Changed code | 98MB | 124MB | 26MB | | ||
+ | \\ | ||
+ | I repeated the experiment with 80 cuts on the same project: | ||
+ | ^ Code ^ mem usage after load ^ mem usage after 80 cuts ^ accumulated memory usage ^ | ||
+ | | Unchanged code | 99MB | 542MB | 443MB | | ||
+ | | Changed code | 99MB | 162MB | 63MB | | ||
+ | \\ | ||
+ | And again with 120 cuts on the same project: | ||
+ | ^ Code ^ mem usage after load ^ mem usage after 120 cuts ^ accumulated memory usage ^ | ||
+ | | Unchanged code | 100MB | 994MB | 894MB | | ||
+ | | Changed code | 99MB | 193MB | 94MB | | ||
+ | \\ | ||
+ | The results points in the direction of the modified code growing approximately linear in size, and the unmodified code growing almost 2 times faster than linear (of course more measurements must be taken in order to determine the exact curve, but the point is that more cuts, the faster it grows)\\ | ||
+ | ^ Graph of memory usage ^ | ||
+ | | {{ : | ||
+ | | The red graph is the unmodified code, the blue graph is the modified code. | | ||
\\ | \\ | ||
//I hope this page might be of some use for the Ardour developers in the continuous work to improve Ardour to become one of the worlds leading DAWs!//\\ | //I hope this page might be of some use for the Ardour developers in the continuous work to improve Ardour to become one of the worlds leading DAWs!//\\ | ||
\\ | \\ | ||
//Written by Bent Bisballe Nyeng (deva@aasimon.org)// | //Written by Bent Bisballe Nyeng (deva@aasimon.org)// |
ardour/memoryleak.txt · Last modified: 2008/11/24 19:24 by deva