MySQL Bugs: #57270: MySQL Workbench has bad memory leak during model diagram manipulations

Bug #57270	MySQL Workbench has bad memory leak during model diagram manipulations
Submitted:	6 Oct 2010 5:38	Modified:	25 Mar 2013 15:36
Reporter:	Karl Nicoletti	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: Modeling	Severity:	S3 (Non-critical)
Version:	5.2.28 CE Rev. 6722	OS:	Windows (Windows XP Pro SP 3)
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	diagram, memory leak, model, performance degradation

Description:
MySQL Workbench 5.2.28 CE Rev. 6722 has a nasty memory leak during object manipulatations in a large model display.  I noticed that performance would noticeably degrade after manipulating objects in a diagram in a model with many tables and foreign key links. I turned on the Windows Task Manager and watched as the Mem Usage for the MySQLWorkbench.exe grew from the 60K at startup to 464,000K within about 20 or so operations. Then simply dragging a table from one position dropping it then dragging it back to another produced the following memory size growth: 487,260K -> 505,460K -> 523,116K!  Swapping sets in and performance goes into the toilet. The workaround is to save the model, and then reopen it. When it take 3 seconds after clicking the mouse for the selection indicators to appear, then I know that I need to reboot the Workbench session.

How to repeat:
In the windows task manager click the Mem Usage to sort from highest to lowest.

Create a model with 50 or so tables each having an average of 12 columns. Connect most of the tables with foreign keys to specific columns. Display all the tables in a single Diagram. Zoom out to view entire model. Select a table object or several table objects and drag them from one position to another. Examine the Windows Task Manager. Drag the same objects back again. Notice that the memory size has grown by another 16,000-17,000K.

Suggested fix:
Workaround is to save the model quit MySQL workbench and then reopen the model.

Just noticed that memory leaks are fairly small in the beginning. If modify a table, like add a column, then the rate of leakage begins to accelerate.

Thank you for the bug report.

I accidently discovered that all memory is RELEASED when MINIMIZING the MWB window! When the window is reactivated the memory stays small until more operations are completed.  Example:

Operation              Mem Usage
-------------------    ---------
Open model             111,848K
Minimize MWB window      2,316K
Activate MWB window     18,016K
Click on a table        33,292K
Open table editor       51,096K
Minimize MWB window      2,144K
Activate MWB window     23,324K

I replicated Karl's observations, also using a very large model (133 tables + 75 views), with Version 5.2.34 CE (Rev 7780). It seems that moving objects around in the model window causes the greatest increase in unreleased memory usage. As Karl observed, I also gain relief by minimizing the application and reactivating it.

Hope someone can figure this one out. It's a real drag to have to shutdown and restart WB every few minutes or so when working on a big model.

A caveat on my comment of September 07 ...
... minimizing WB releases memory it holds, but it /does not/ free the Page File Commit Charge. Memory pages are still held in the Page File and recalled when needed. The page file will continue to grow until it asymptotically approaches its maximum, at which time WB will crash. The only way to free those memory pages is to close WB and restart it.

I respectfully suggest the severity of this bug be escalated to S2 (Serious)

No reproducible in the latest WB Version
Verified in:
Ubuntu 12.04x64
Windows7x64
WB 5.2.46 rev.10385

This appears to be fixed in 5.2.46 SE Revision 10385.

Looks like this is fixed for modeling in MWB 5.2.46 SE. However here is still a memory leak in the MWB 5.2.46 SE "DBDoc - Model Reporting." See BugID# 68755.

Don't know if I'm the one who is supposed to close this bug but I will do so with this posting.