Excessive CPU load when LogCat loses connection

[Carl Henrik Janson]

On even a powerful machine, CPU load can be as high as 25-40% when NBAndroid looses connection to the logcat flow. Very often, the "evidence" of a lost connection would be visible if you disconnect the Android device from USB. Immediately, the missing logcat messages are flowing into the NBA logcat window.

At other times, the message flow is painstakingly slow. There could be a "funny" delay of up to one minute.

When this happens, it is necessary to start the Android debug monitor to continue the work.

This bug is present across various Windows machines and across various NetBeans versions. In other words, it is suspected this has something to do with NBA.

[Radim Kubacki]

I can't reproduce it at the moment (using my Nexus 5 + Debian machine). Given that you see it repeatedly can you: * add a log file with logging enabled as described in http://nbandroid.org/#contact (send it to radim at kubacki dot cz if you do not want to attach it here). Add -J-Dorg.nyerel.nbandroid.logcat.level=FINE to options mentioned in the linked page. * add a thread dump taken when the load on your machine is high - http://wiki.netbeans.org/GenerateThreadDump

Hopefully this will give as some clue about the reason of this behavior. Also it is possible that closing / re-opening ADB log window can be related to when this is triggered.

[Robert Tuck]

I am seeing something similar to this on my machine when I am connected with Samsung S5. (Other devices I have don't seem to be nearly as bad, possibly because logcat buffers are smaller or log messages are not as copious). Google searches seem to indicate that Samsung devices are notorious for log spam so guess this may be the case on other Galaxy devices.

Symptoms are that if device is disconnected for any period of time (such that a backlog of messages is built up), then reconnect the device, it will take up to tens of minutes to catch up a similar period of missed log messages. Regions of dense logging are several times (10-20 x) slower than realtime. Clearing the filter has no effect. It is easily possible to generate log messages faster than they can be consumed.

This is definitely an issue with NBAndroid, as using monitor sdk tool, the log messages are retrieved instantly. Unfortunately monitor tool is totally unusable for searching logs.

I just did some cursory profiling with jvisualvm, which seemed to indicate that org.nyerel.nbandroid.LogReader.processLogLines() was chewing CPU in ArrayList.contains() calls.

Unfortunately I don't have a NetBeans dev environment set up to debug any further.

[Carl Janson]

I would like to confirm Robert Tuck's descriptions. I can add that NBA, when this error hits in, will slow down the logcat feed and often be several minutes behind in schedule. It can be helpful to restart NB, but often a pc restart is the quickest remedy. The problem could somehow be related to the usb drivers under Windows, but why then are the Android monitor tool not subject to the same error? Most likely something to do with the NBA.

An acceptable solution would be to have a non-compromizing reset button for the logcat, a button that would just kill the log feed process and start a new.

[Robert Tuck]

Attached patch which I've been trying out today and it seems to speed up log retrieval significantly

[Radim Kubacki]

Patch applied in 1.272

[Radim Kubacki]

Thanks for the patch!

[Carl Janson]

How is this patch installed?