search

jpaulm / drawfbp

Tool for Creating and Exploring Flow-Based Programming Diagram Hierarchies
http://www.jpaulmorrison.com/fbp/
146 stars 20 forks source link

CPU usage of DrawFBP is a little high on my Windows 7 (jre-1.8.0_133 x64), why? #12

Closed pimgeek closed 6 years ago

pimgeek commented 7 years ago

Please see the following screenshot to get a basic idea, I could provide more info if necessary.

image

I was trying to modify a simple Network Diagram, like this: image

If the CPU usage stays high like this, I may have to maintain network connections by hand. :disappointed:

ERnsTL commented 6 years ago

This is also the case for me (though different OS and Java 1.8.0_181) using DrawFBP v2.14.2.

It fully saturates one CPU core.

As far as I can see using a syscall trace, it is constantly doing a poll on a file description, then immediately trying to read from it and most of the time gets back -1 EAGAIN (Resource temporarily unavailable).

Running this in an actual Java debugger would show the cause in more detail.

jpaulm commented 6 years ago

Not sure what "poll" means. Also Googling this problem suggests EAGAIN only happens on a "write" - which I guess is not the case... I found this: https://groups.google.com/forum/#!topic/linux.debian.user/yMLyIeDMsZ8 , but it involves Debian - maybe not the same problem...? Anyway, I don't get any errors when running Eclipse debug - can you suggest how I can switch this on...? TIA

ERnsTL commented 6 years ago

Regarding polling:

But the program does not wait for an event to happen, but tries to immediately do a read on the file descriptor and gets an error because no event has arrived yet ... and keeps getting an error until finally an event arrives.

To sum it up, the program seems to be in a loop checking for input events or constantly redrawing the display area or something similar.

Does DrawFBP maybe have a main loop or event loop which could be constantly busy?

Interestingly, when running the .jar in the Java debugger, it does not behave that way... but when running the .jar regularly without enabling debugging, then it saturates a CPU core, running in a loop:

poll, read with error, read with error, read with error, .... read with success (finally received an event) ... poll again, read with error, read with error, read with error, ....read with success etc.

I will also check this more in-depth.

jpaulm commented 6 years ago

Thanks, Ernst! I suspect this involves Java Swing's event-handling. I use invokeLater for some of the focus stuff and I have quite a lot of Listeners looking out for various events. There is no main loop...

The problem may be too many repaints - see https://stackoverflow.com/questions/49136035/java-frequent-repaint-has-too-high-cpu-usage ... I am trying reducing the number of repaints, and it looks interesting! I am going to commit these changes, as v2.15.0, so that you (or anyone else) can play with it!

I haven't had a lot of time yet to dig into it, but I'll do some experimenting when I get a chance, to see if I can bring down the CPU without impacting responsiveness - maybe it's something simple! Cheers

jpaulm commented 6 years ago

I feel pretty sure this problem involves redrawing "dirty" areas - repaint() seems to be creating a "dirty" area, which immediately triggers another repaint(), resulting in a tight loop. So, yes, I am looping, but not intentionally! It would be a great help if someone - @ERnsTL or @pimgeek or anyone... - could suggest a way to find the dirty area or areas... Meanwhile, I will keep digging!

jpaulm commented 6 years ago

I think I have fixed this in v2.15.1. The VisualVM profiler reports CPU usage dropping from 25% to around 5%.

@ERnsTL or @pimgeek, I would appreciate it if you could so some testing...

@bobcorrick, could you do your regression testing? Thanks a million to all of you!

ERnsTL commented 6 years ago

Just tested 2.25.1 - it is definitely an improvement.

The CPU usage seems to have shifted. DrawFBP itself is now using about 50/60 % as much as before, but now the display server is maxing out its CPU core. It seems like DrawFBP is waiting for the result of an expensive graphics operation (maybe getting dirty areas or something similar?).

In v2.14.2 it was the other way around; DrawFBP using a full core plus the display server half a core (which is also a lot).

So much for what is observable on my machine.

jpaulm commented 6 years ago

Thanks so much! So there is an improvement, but we're probably still getting dirty areas. . Any idea how I can find them? Is there a tool that can walk the tree of components? Or maybe I don't understand how dirty areas get created...? Thanks in advance!

bobcorrick commented 6 years ago

Hi Paul, I'll be able to find time for this over the next few days: family matters are keeping us busy (grandchildren). Glad to see that you are still maintaining DrawFBP. I've had a break from technical work this year, so I now need to set up a laptop to get back into it for the regression testing. All the best to you and yours, Bob.

On 29 Aug 2018, at 03:00, Paul Morrison notifications@github.com<mailto:notifications@github.com> wrote:

I think I have fixed this in v2.15.1. The VisualVM profiler reports CPU usage dropping from 25% to around 5%.

@ERnsTLhttps://github.com/ERnsTL or @pimgeekhttps://github.com/pimgeek, I would appreciate it if you could so some testing...

@bobcorrickhttps://github.com/bobcorrick, could you do your regression testing? Thanks a million to all of you!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/jpaulm/drawfbp/issues/12#issuecomment-416797820, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHKwpNPSIaqun-hffoezjGEzk3Sautg7ks5uVfWfgaJpZM4N9XL5.

bobcorrick commented 6 years ago

Hi again Paul, I now have Java set up on a Win 10 laptop, but cannot see the latest DrawFBP via the maven.orghttp://maven.org link - only the 2.14 one. I was expecting to see v 2.15.2 according to the GitHub remarks, Kind regards, Bob.

On 2 Sep 2018, at 09:39, Bob bobcorrick@outlook.com<mailto:bobcorrick@outlook.com> wrote:

Hi Paul, I'll be able to find time for this over the next few days: family matters are keeping us busy (grandchildren). Glad to see that you are still maintaining DrawFBP. I've had a break from technical work this year, so I now need to set up a laptop to get back into it for the regression testing. All the best to you and yours, Bob.

On 29 Aug 2018, at 03:00, Paul Morrison notifications@github.com<mailto:notifications@github.com> wrote:

I think I have fixed this in v2.15.1. The VisualVM profiler reports CPU usage dropping from 25% to around 5%.

@ERnsTLhttps://github.com/ERnsTL or @pimgeekhttps://github.com/pimgeek, I would appreciate it if you could so some testing...

@bobcorrickhttps://github.com/bobcorrick, could you do your regression testing? Thanks a million to all of you!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/jpaulm/drawfbp/issues/12#issuecomment-416797820, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHKwpNPSIaqun-hffoezjGEzk3Sautg7ks5uVfWfgaJpZM4N9XL5.

jpaulm commented 6 years ago

Sorry about the confusion! I had some stuff from 2.15.0 still on Github - I didn't realize that some assets would get left even after I deleted the release!

v2.14.2 is the last (fairly) good one, but it has this CPU usage problem... v2.15.1 tried to solve it, and improved it a bit, but still no luck! I am zeroing in on the problem, but haven't quite solved it, so v2.15.1 is only Pre-release! Hope to get a solution in the next few days! Fingers crossed!

jpaulm commented 6 years ago

Dumb mistake, I think, but it's been in the code for ages!!! Thanks to @ERnsTL and @pimgeek for pointing it out. Sorry, @pimgeek, that I didn't pick up on your issue a long time ago!

I think I have fixed this in v2.15.2. Task Manager now shows little blips, rather than one core running at around 90% ! The VisualVM profiler looks very different now!

@ERnsTLhttps://github.com/ERnsTL or @pimgeekhttps://github.com/pimgeek, I would appreciate it if you could so some testing...

@bobcorrickhttps://github.com/bobcorrick, could you do your regression testing, at your leisure, of course!? Thanks a million to all of you!

You can get the latest version from GitHub/DrawFBP/Releases jar file for v2.15.2.

ERnsTL commented 6 years ago

Just tested the new 2.15.2 - CPU usage is all practically zero when no diagram loaded, when minimized, with normal window size, when network diagram opened.

This issue looks fixed to me. Thanks for hunting this down, Paul!

bobcorrick commented 6 years ago

Hi Paul,

I just had a short test session, late in the day - now 22:45 local time.

REPORT Regression test using Windows 10 laptop, DrawFBP 2.15.2 - basic menu and drawing operations ok. There were a couple of observations: File > Display Properties did not show a property list File > Change Fonts- Text for the version number does not change when font or size is changed.

I did not exercise complex diagram creation yet, as I did not find the JavaFBP jar file: could you help me with that, please?

More soon, and kind regards to you, All the best, Bob.

On 8 Sep 2018, at 22:03, ERnsTL notifications@github.com<mailto:notifications@github.com> wrote:

Just tested the new 2.15.2 - CPU usage is all practically zero when no diagram loaded, when minimized, with normal window size, when network diagram opened.

This issue looks very fixed to me. Thanks for hunting this down, Paul!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/jpaulm/drawfbp/issues/12#issuecomment-419672655, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHKwpJeg1Ro_rCjDXlk14P78rgNloLg2ks5uZDCegaJpZM4N9XL5.

ERnsTL commented 6 years ago

Greetings Bob, If you are looking for the released pre-compiled DrawFBP .jar file:

  1. This is a release artifact and can be found starting at the repository web page.
  2. above the horizontal colored bar there is "123 commits ... 1 branch ... 51 releases ... 2 contributors " -- click on "releases".
  3. In the releases list, the v2.15.2 should already be the top entry.
  4. In that entry, there is a list of attachments - the source code in zip and tarred form ... and the pre-compiled DrawFBP .jar file.
jpaulm commented 6 years ago

Many thanks, @ERnsTL, that's great news! I have marked this issue closed. Thanks again!

jpaulm commented 6 years ago

@bobcorrick , thanks for the testing! @ernstl's comment about finding the JavaFBP jar file is correct, but applies to the JavaFBP repository, and the latest release is v4.1.0, so the jar file can be found at https://github.com/jpaulm/javafbp/releases/tag/v4.1.0 .

Thanks for your comment about not seeing the properties list. I believe I have found the cause, and I will include this in v2.15.3.

Same thing for version number font not changing. Thx again!

jpaulm commented 6 years ago

By the way, @ERnsTL , you were right! It was effectively a loop: I was issuing a repaint inside a paintComponent method! I didn't realize it, but that resulted in a tight loop! Best regards, P.

ERnsTL commented 6 years ago

Ah, just noticed that Bob was asking for the jar file for JavaFBP not DrawFBP. Ah, anyway ;-)

@jpaulm: Glad you found the issue! These event- and component-driven frameworks are are all good and nice... but getting an overview of the event flow and which component causes a repaint ... I am sure this was difficult to trace.

Thanks again for staying on it and hunting it down. Best Greetings, Ernst