Bug 72644 - Code generation and undo/redo take up too much memory
Summary: Code generation and undo/redo take up too much memory
Status: RESOLVED FIXED
Alias: None
Product: umbrello
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Umbrello Development Group
URL:
Keywords:
: 74242 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-01-14 16:22 UTC by Sean Clarke
Modified: 2013-11-06 17:35 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sean Clarke 2004-01-14 16:22:48 UTC
Version:            (using KDE KDE 3.1.94)
Installed from:    Unspecified Linux
OS:          Linux

I was using Umbrello for about 1-2 hours and I noticed that I using a lot of memory. During that time Umbrello had grown to ~500MB.

I was puzzled as I had used it for longer periods and had not "noticed" any excessive memory usage.

I played about and discovered I could get Umbrello to grow 100MB in less than 2 minutes by selecting around different diagrams and (more importantly) just by moving the classes in my sequence diagrams around.

Just select a class, move it left a bit, then right a bit etc. very soon the memory footprint is huge. I had not "noticed" this with the class diagrams.

I am using Umbrello compiled from source (kdesdk-040113 ie 13/01/2004).

I think the leak is very large and this should be considered as critical.
Comment 1 Sean Clarke 2004-01-15 11:12:26 UTC
Some more info..

I have tested it and it appears the problem is present with class diagrams, so it looks like all diagrams are affected.

I've tried to start umbrello with valgrind, I left it for 30 minutes to startup and it still hadn't started (P4 1.7Ghz + 1.2GB RAM) so I killed it.

Any options I can use on valgrind to assist in finding the leak?
Comment 2 Jonathan Riddell 2004-01-19 17:33:33 UTC
I suspect this is due to the undo/redo stack which just saves a copy of the diagram in memory.  The code generation information might mean this now takes up too much memory.
Comment 3 Sean Clarke 2004-01-19 18:46:53 UTC
It could be, sort of makes sense why I didn't see it before.

It is an exceptionaly large leak though.
Comment 4 Jonathan Riddell 2004-02-05 16:54:15 UTC
*** Bug 74242 has been marked as a duplicate of this bug. ***
Comment 5 Brian Thomas 2004-02-17 19:20:08 UTC
I would think that reducing the number of "modified()" calls within umbrello
would also help out with this. Another thought: does umbrello allow the user
to control the size of the undo stack? We could have that default to a smaller
number, and allow the user to pick a higher one should their hardware be 
more capable.

Comment 6 Piotr Kolaczkowski 2004-04-13 16:09:00 UTC
Why not remember only the CHANGES to the diagram, not a copy of the whole diagram? Or only copies of the modified widgets (worse, but easier)?
Comment 7 Jonathan Riddell 2004-04-14 19:02:33 UTC
> Why not remember only the CHANGES to the diagram, not a copy of the whole
> diagram? Or only copies of the modified widgets (worse, but easier)?

It's much harder to implement.

All patches welcome of course :)
Comment 8 Sebastian Stein 2004-07-29 15:46:49 UTC
I think this problem is mostly gone with the patches by Achim. Of course the memory usage still grows with the time, but this is a normal thing. And yes, Umbrello has great leaks, but this is a different problem. And now you can turn of undo/redo completely. So I mark the problem as fixed.
Comment 9 Thibault Normand 2007-04-11 16:56:27 UTC
[r652562] Switch the undo/redo feature to KUndoStack based on QUndoStack from Qt4.2. It's an "action" based undo/redo pattern only save the action chain in the undo/redo stack, but the state between actions.
Comment 10 Ralf Habacker 2013-11-06 17:35:15 UTC
set version-fixed-in from 4.0.0 changelog