Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
pimgeek opened this issue Jun 17, 2017 · 19 comments
Closed

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

pimgeek opened this issue Jun 17, 2017 · 19 comments

Comments

@pimgeek
Copy link

pimgeek commented Jun 17, 2017

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. 😞
@ERnsTL
Copy link

ERnsTL commented Aug 20, 2018 •
edited
Loading

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
Copy link
Owner

jpaulm commented Aug 20, 2018

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
Copy link

ERnsTL commented Aug 21, 2018 •
edited
Loading

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
Copy link
Owner

jpaulm commented Aug 21, 2018 •
edited
Loading

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
Copy link
Owner

jpaulm commented Aug 25, 2018

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
Copy link
Owner

jpaulm commented Aug 29, 2018

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
Copy link

ERnsTL commented Aug 29, 2018

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
Copy link
Owner

jpaulm commented Aug 29, 2018 •
edited
Loading

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
Copy link

bobcorrick commented Sep 2, 2018 via email

@bobcorrick
Copy link

bobcorrick commented Sep 2, 2018 via email

@jpaulm
Copy link
Owner

jpaulm commented Sep 2, 2018

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
Copy link
Owner

jpaulm commented Sep 8, 2018 •
edited
Loading

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
Copy link

ERnsTL commented Sep 8, 2018 •
edited
Loading

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
Copy link

bobcorrick commented Sep 8, 2018 via email

@ERnsTL
Copy link

ERnsTL commented Sep 9, 2018

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 jpaulm closed this as completed Sep 9, 2018
@jpaulm
Copy link
Owner

jpaulm commented Sep 9, 2018 •
edited
Loading

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

@jpaulm
Copy link
Owner

jpaulm commented Sep 9, 2018 •
edited
Loading

@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
Copy link
Owner

jpaulm commented Sep 10, 2018

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
Copy link

ERnsTL commented Sep 10, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jpaulm @pimgeek @ERnsTL @bobcorrick