CPU usage of DrawFBP is a little high on my Windows 7 (jre-1.8.0_133 x64), why? about drawfbp HOT 19 CLOSED

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.

from drawfbp.

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

from drawfbp.

Regarding polling:

• Information 1
• Busy waiting
• The according system call is also called poll.

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.

from drawfbp.

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

from drawfbp.

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!

from drawfbp.

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!

from drawfbp.

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.

from drawfbp.

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!

from drawfbp.

from drawfbp.

from drawfbp.

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!

from drawfbp.

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.

from drawfbp.

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!

from drawfbp.

from drawfbp.

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.

from drawfbp.

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

from drawfbp.

@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!

from drawfbp.

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.

from drawfbp.

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

from drawfbp.