bugDenemo - Bugs: bug #32371, Breve and Longa cause high cpu...

 
 

bug #32371: Breve and Longa cause high cpu usage on windows, denemo uses 206 megs of ram

Submitter:  None
Submitted:  Sun 06 Feb 2011 06:36:10 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 16 Feb 2011 02:54:12 AM UTC, comment #17: 

Wow, nice work.  Look forward to testing it.
-Dan W.

Anonymous
Tue 15 Feb 2011 10:04:20 AM UTC, comment #16: 

no more 4k per draw cycle. If there are any further issues here, can we have a new bug report please.

Richard Shann <rshann>
Group administrator
Tue 15 Feb 2011 09:22:26 AM UTC, comment #15: 

It occurs to me that I don't really have any good tool for this - 4k is rather a small amount of memory relative to the total on modernish machines. And, sure enough, I have left Denemo running with the cursor blinking and I can see the memory usage climbing - using a default setting of top(1) it has grown from 4.1% to 4.5 so it is leaking on Linux.
I also think I can see why - the cairo routines create a cairo_t object every draw and never destroy it.
I'll test out a fix next...
It is likely that this cairo implementation of the drawing is also the source of the bad performance of playback. Any cairo experts around???

Richard Shann <rshann>
Group administrator
Mon 14 Feb 2011 11:37:06 PM UTC, comment #14: 

Good point.  I tested with cursor highlight disabled on a 0.8.19 version, and-at least after a restart-the ram usage does NOT show the steady increase.  So for once one of my speculations turned out to be correct, as it does continually gobble 4K per second with the blinking cursor enabled.
-DW

Anonymous
Mon 14 Feb 2011 02:21:43 PM UTC, comment #13: 

to test the blinking cursor connection turn it off - via prefs "highlight cursor" pref (and then re-start? :()

Richard Shann <rshann>
Group administrator
Mon 14 Feb 2011 01:42:19 PM UTC, comment #12: 

Tested a 0.8.19 version on a different machine, a dell laptop with windows xp professional, and observed the same steady ram gobbling after moving the task manager on top of the denemo window.

I'm guessing the steady 4K-per-second ram gobbling is related to the blinking cursor, since it was not observed in the 0.8.16 which didn't have a blinking cursor.  Even if that guess is true, the source of the problem may have little to do with that.
-DW

Anonymous
Sun 13 Feb 2011 06:30:00 PM UTC, comment #11: 

0.8.16 shows ram usage increase when I wiggle the task manager on top of denemo, but not the steady climb I saw in 0.8.22 and on. 

I have another machine I can try to test this stuff on.  I'm guessing it's simply a bug in the video driver or something similar.  If it looks like it is specific to denemo I'll post more info here, but if it's fine on vista, it's probably not denemo causing the quirks. -DW

Anonymous
Sun 13 Feb 2011 06:17:48 PM UTC, comment #10: 

Yes I waggled the task mananger window over the top of Denemo, and saw no effect. The window manager (vista) must be caching the re-draw. I added Breves and saw nothing unusual :(

Richard Shann <rshann>
Group administrator
Sun 13 Feb 2011 05:39:35 PM UTC, comment #9: 

The same score with breve and longa does show 40% cpu usage on the 0.8.22 version.  Has this been observed anywhere else?
-Dan

Anonymous
Sun 13 Feb 2011 05:37:50 PM UTC, comment #8: 

I just tested 0.8.22 on windows xp, first deleted the old .denemo.  It does indeed show the memory-gobbling: it can be started by opening up the task manager and wiggling around its window on top of the denemo display twice or so.

When you tested the 0.8.22 on vista, did you open up another window on top of denemo and move it around so that it has to redraw a lot?  If so, and no memory gobbling occurred, then I don't know what to make of this issue.  No other apps do this on my machine, none that I've observed anyway.  Maybe I'll check out earlier versions to see if older versions don't do this or what.

-Dan

Anonymous
Tue 08 Feb 2011 01:19:09 PM UTC, comment #7: 

I have just tested 0.8.22 on vista and it does not show the memory gobbling on re-draw.

Richard Shann <rshann>
Group administrator
Mon 07 Feb 2011 12:22:58 AM UTC, comment #6: 

I just tried the same experiment with the gimp on windows, to see if maybe it was a gtk on windows problem or 'feature'.  I couldn't get the ram to climb but I could get the total ram usage to drop from 88M at startup, to about 18M stable just by minimizing then maximizing.  So that's probably not a denemo issue itself, I'm thinking.  Actually the same result is observed on ms word (drop in ram usage from minimizing then maximizing) so it's probably a quirk of the operating system.

In summary: the observation about ram shrinking from 55 down to 8 is probably spurious.
-Dan

Anonymous
Mon 07 Feb 2011 12:11:35 AM UTC, comment #5: 

Ugh.
The 206 megs was due to the soundfont I was using.
Sorry about that.

No forehead-slapping explanation found for the ram usage climb.

This is tested on the latest in-between release for windows.

This is one way I can provoke the ram climb (in windows xp):
Open the denemo score. If I open a window and move that window around raplidly ON TOP OF the denemo window, RAM consumption increases dramatically, about 500K per second of moving, and then climbs from there. 

Bizarrely:
Minimizing and then maximizing seems to shrink denemo's memory consumption from the stable startup value of 55 Megs down to 8 Megs, for some reason.  It then stays low!  Anytime the ram gets too high, I can just minimize then maximize to get it back to about 8  megs.

To answer your question, I can get the ram usage to climb with a completely empty score on denemo just by moving another window around on top of the denemo window so that it redraws rapidly.

As far as whether the other symptoms (high cpu) require breves, I'm not 100% sure but just opening the attached score with breves and longas sends cpu to 37 and it stays there indefinitely.  Making a similar score with whole notes has no such problem.

Hope this helps.
-Dan

Anonymous
Sun 06 Feb 2011 10:22:01 PM UTC, comment #4: 

Thanks for this - the undo only allocates memory as each step is taken so it is not undo. And indeed, you have shown the the draw routine is losing memory.
Is it doing so with an empty score, or do you have to have notes or do you have to have a Breve?
I'll see if I can see a similar story on Linux.

Richard Shann <rshann>
Group administrator
Sun 06 Feb 2011 08:04:26 PM UTC, comment #3: 

I don't think the 206 MB is from undo, because it's at that from the time I start up denemo, unless you allocate all the memory in advance at startup for tons of undoing stored as complete files rather than "delta- encoded"? (I don't know how you guys implemented undo, but
Also, I just opened denemo to verify the 206 MB, entered about 8 whole notes, and watched the memory usage climb steadily by 4K every second long after I stopped doing anything.  I'm not sure I have time to do this, but maybe it would be good if someone tried out all the git-built windows versions to find when these things first arose.

Anonymous
Sun 06 Feb 2011 07:10:34 PM UTC, comment #2: 

Unfortunately the bug reported in the console is not relevant - you can safely ignore it. The 206 Mb usage - would this be Undo that is gobbling up memory. (That is, it does eat up memory, but is that what your 206Mb is about?). We have no way to turn off undo, and I think doing a d-New will leak the memory :(, so re-start Denemo and re-load the file to see.
The "while doing absolutely nothing" is perhaps the display refreshing? I notice that it refreshes every 0.1 seconds, I don't remember why.
No-one has looked into any of this stuff yet - it is great to get at least some insights - thank you.

Richard Shann <rshann>
Group administrator
Sun 06 Feb 2011 06:52:43 PM UTC, comment #1: 

The console shed a bit of light on this.  Maybe it's already fixed in the new version, in which case I apologize.
Attached is a png of the console output (no way to select it as text) with a few breves and longas.  Mentions a bug in librsvg.
Hope this helps.
-Dan



Anonymous
Sun 06 Feb 2011 06:36:10 PM UTC, original submission:  

Hi,
While writing a simple piece to test out rebar with breves and longas, I noticed denemo's performance start to lag seriously.  The cpu usage got up to in the 35 % range while doing absolutely nothing.  As I deleted breve and longas, the cpu usage dropped back down to 1%.  You can see if anything similar happens with this file.  This was observed on windows xp.

Also, how long has denemo been using 206 megs of ram??  Seems outlandish to me.  I thought it used 50 or so last I checked.

This was a somewhat recent 0.8.23 build, probably the one before the most recent that was posted to the mailinglist.

-Dan W.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #22612:  Errors.png added by None (65KiB - image/png)
file #22611:  RebarGauntlet.denemo added by None (19KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rshann (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-07-24 rshann Open/ClosedOpen Closed
    2011-02-15 rshann StatusNeed Info Fixed
    2011-02-08 rshann StatusNone Need Info
    2011-02-06 None Attached File- Added Errors.png, #22612
    2011-02-06 None Attached File- Added RebarGauntlet.denemo, #22611

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code