How to use JProfiler (or other tools) to trouble shoot non-responsive UI threads?

Ignition
,
1

I have a button that opens a popup window. It opens it with a single 'id' parameter, used in a named query, which runs with a good execution plan (the id is the primary key). Minimal scripting on the window etc, but every time the window attempts to open - there is a 3-4 second pause and I get a nonresponsive-edt file. Here's the latest -
NonResponsiveEdt-2024-11-06_124452.json (52.0 KB)

I have the evaluation version of JProfiler and am able to attach it to my running vision instance. What exactly would I want to be doing with it to try to troubleshoot this? Thread dump right after the button click/unresponsiveness?

2

The stack trace for the EDT thread points to the file explorer component loading an icon from the filesystem being the culprit:

java.base@17.0.12/jdk.internal.misc.Unsafe.park(Native Method)
java.base@17.0.12/java.util.concurrent.locks.LockSupport.park(Unknown Source)
java.base@17.0.12/java.util.concurrent.FutureTask.awaitDone(Unknown Source)
java.base@17.0.12/java.util.concurrent.FutureTask.get(Unknown Source)
java.desktop@17.0.12/sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Unknown Source)
java.desktop@17.0.12/sun.awt.shell.ShellFolder.invoke(Unknown Source)
java.desktop@17.0.12/sun.awt.shell.ShellFolder.invoke(Unknown Source)
java.desktop@17.0.12/sun.awt.shell.Win32ShellFolder2.getIcon(Unknown Source)
java.desktop@17.0.12/javax.swing.filechooser.FileSystemView.getSystemIcon(Unknown Source)
com.inductiveautomation.factorypmi.plugins.reporting.components.FileExplorer$FilesystemTreeNode.getIcon(FileExplorer.java:269)
com.inductiveautomation.factorypmi.plugins.reporting.components.FileExplorer$FileNodeRenderer.getTreeCellRendererComponent(FileExplorer.java:436)
java.desktop@17.0.12/javax.swing.plaf.basic.BasicTreeUI$NodeDimensionsHandler.getNodeDimensions(Unknown Source)
java.desktop@17.0.12/javax.swing.tree.AbstractLayoutCache.getNodeDimensions(Unknown Source)
java.desktop@17.0.12/javax.swing.tree.VariableHeightLayoutCache$TreeStateNode.updatePreferredSize(Unknown Source)
1 Like
3

You'd want to make sure you're in instrumentation mode, as opposed to sampling, and then attach and start CPU recording. Then do the thing that is slow. Then stop recording, and look at the CPU view and see what was slow (hopefully).

1 Like
4

Thanks that is good to now - I have other bottle neck areas I need to do that on. However, your first answer was exactly the issue - apparently this window has a file tree component hidden and loading every window open, no wonder it was slow.

1 Like