User Tools

Site Tools


ardour:memoryleak

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
ardour:memoryleak [2008/11/12 21:52] devaardour:memoryleak [2008/11/24 19:24] (current) deva
Line 1: Line 1:
 =====The Ardour memory leak===== =====The Ardour memory leak=====
 +^ **UPDATE:** As of svn revision r4240 (Ardour v2.7.1), the problem seems fixed. ^
 +
 +\\
 Ardour has for a very long time been having a pretty nasty memory leak, somehow connected to its undo history list.\\ Ardour has for a very long time been having a pretty nasty memory leak, somehow connected to its undo history list.\\
-The author implemented a way to no store more than a given number of elements in the list, but this did not seem to fix the issue.\\+The author implemented a way not to store more than a given number of elements in the list, but this did not seem to fix the issue.\\
 The problem manifests itself whenever an action is performed, by allocating an amount of memory, growing with number of actions taken to reach the current point in the project. In other words, the longer you work, the more memory one action will take up.\\ The problem manifests itself whenever an action is performed, by allocating an amount of memory, growing with number of actions taken to reach the current point in the project. In other words, the longer you work, the more memory one action will take up.\\
 The leak is particularly nasty when working on big projects with 16 or more tracks, in which high end computers with as much as 4GB of memory will quickly be sent to its knees.\\ The leak is particularly nasty when working on big projects with 16 or more tracks, in which high end computers with as much as 4GB of memory will quickly be sent to its knees.\\
Line 57: Line 60:
 | Changed code   | 99MB | 162MB | 63MB | | Changed code   | 99MB | 162MB | 63MB |
 \\ \\
-The results points in the direction of the modified code growing approximately linear in size, and the unmodified code growing almost 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)\\+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 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 ^ 
 +| {{ :ardour:ardour_memleak.png }} | 
 +| 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.1226523140.txt.gz · Last modified: 2008/11/12 21:52 by deva