Forum Stats

  • 3,837,260 Users
  • 2,262,244 Discussions
  • 7,900,240 Comments

Discussions

Very long time to open catalog in file manager in 22.2

jsqfel
jsqfel Member Posts: 31 Blue Ribbon

Hello,

I observed very long time to open folder in file manager when open file in 22.2.

In previous version it was a moment.

Please fix it in next version.

«1

Comments

  • user9540031
    user9540031 Member Posts: 222 Gold Badge

    Hi,

    Which version of Windows are you using?

    I noticed the same issue—yes, that's how bad it is—on my old home Win 7 box... But that's Windows 7, hence no longer supported.

    It didn't strike me as an obvious problem on Window 10—but unsure, as font scaling issues mostly kept me on 21.4.3 so far, so I'll have to do more tests in any case.

    Regards,

  • jsqfel
    jsqfel Member Posts: 31 Blue Ribbon

    Using Windows 10.

  • thatJeffSmith-Oracle
    thatJeffSmith-Oracle Distinguished Product Manager Posts: 8,687 Employee

    Please describe in more detail what is happening.

    1 - where is that folder

    2 - how many files are in it

    3 - what is taking a long time - to get the file list, something else?

    4 - Version of Java?

    I'm not seeing latency issues browsing local folders on windows 10, SQLDev 22.2, and Java 11

    Something to try, disable this preference and restart SQLDev -

    Preferences - Environment - Persist file name and directory paths

  • user9540031
    user9540031 Member Posts: 222 Gold Badge

    Hi,

    Looking further into this issue...

    Of course I can't speak for the OP, but since I believe I have the same issue on my old (unsupported) Windows 7 box, as told I made a couple of tests, both on Windows 7 and 10.

    My old Windows 7 PC at home is by far the most severely affected—to the extent that I consider 22.2.0 mostly unusable on that machine: there it takes no fewer than 18 seconds to open the File -> Save As... dialog.

    (That time is spent in the AWT-EventQueue-0 thread, after clicking on Save As... in the menu, and before the Save As dialog opens. The GUI is frozen in the meantime.)

    The destination folder is a plain folder on a local NTFS filesystem, on a fast SSD drive. This folder contains approx. 300 files.

    On another machine, the fairly recent Windows 10 laptop that I use in my day job, the File -> Save As... dialog feels slower on 22.2.0 than it does on 21.4.3, but not to such a dramatic extent: I'd say the Save As dialog opens within 1-2 seconds—slow, but tolerable.

    My usage pattern is quite similar: approx. 300 files in the destination folder. The filesystem in on a NAS with versioning enabled, though.

    Remark: the "Persist file names and directory paths" checkbox has always been checked, on all my deployments.

    Now, after copying the folder to a NTFS filesystem on the internal SSD drive, and artificially inflating the count of files to approx. 10k, the difference in speed between 21.4.3 and 22.2.0 becomes blatant: the Save As dialog takes 3 seconds to open in 21.4.3, and more than 30 seconds on 22.2.0.

    But... I have reproduced that 10k-files-in-folder test on another, brand new, fast Windows 10 laptop, and there the Save As dialog opens in less than 1 second on 22.2.0, so it would seem that other factors may come into play here—your mileage may vary.

    Using CPU sampling in VisualVM during the File -> Save As... action on affected PCs shows that the time is mostly spent in calls to the java.io.WinNTFileSystem.getBooleanAttributes native method.

    Using Microsoft (SysInternals) Process Monitor to record operating system calls during the opening of the Save As dialog shows that 22.2.0 behaves differently from 21.4.3, making a significantly higher number of system calls.

    The following figures and pictures are from my Windows 7 PC, but the pattern of behaviour are similar on Windows 10; what changes from one system to the other is the induced performance difference.

    Procmon Stack Summary tool for SQL Dev. 21.4.3

    Note the count of events: 964

    Procmon Stack Summary tool for SQL Dev 22.2.0

    Note the count of events: 9272—SQL Dev 22.2.0 did nearly 10x as many system calls as 21.4.3 while opening the Save As dialog.

    Further, the File Summary tool in Process Monitor shows that 22.2.0 made hundreds of calls on the same paths, namely the roots of the filesystems on the host:

    SQL Dev 21.4.3 did not do that.

    (And as shown, I have a few local filesystems on this host... My day-job Windows 10 PC has a couple of network mounts too; on the contrary, the high-perf test Windows 10 PC has only a single filesystem, on its internal SSD.)

    Now, it may strike the reader that there is a huge discrepancy between the File Time as reported by Process Monitor, which records the time spent in servicing the Windows OS system calls (total: 0.27 s), and the wall clock time of 18 seconds, which on the other hand matches the sampled time in VisualVM closely. In other words, the OS system time is next to nothing compared to the Java application time. I have no explanation for that: the CPU usage is low, GC activity is nil, it would seem that the lost time is entirely unaccounted for... Puzzling.

    Bottom line: yes, the behaviour of the File -> Save As dialog has changed in SQL Developer 22.2.0, which appears to make a higher amount of native OS system calls than 21.4.3 in tested situations. Exactly how many more probably depends on local factors, such as how many filesystems exist on the host. The related performance penalty may vary vastly. This will probably go unnoticed by most users, while others may be severely affected.

    Regards,

  • thatJeffSmith-Oracle
    thatJeffSmith-Oracle Distinguished Product Manager Posts: 8,687 Employee

    Windows 7 is a non-starter.

    I'll ask our dev to take a look at the additional calls being made. We updated the framework but it was supposed to be security patches only.

    user9540031
  • John McGinnis-Oracle
    John McGinnis-Oracle Member Posts: 245 Employee

    In your testing of 21.4.3, what version of the JDK are you using? If you are testing with JDK 8, can you try running the same tests with JDK11? Also, can you get a thread dump after the selection of Save As while things are waiting?

  • user9540031
    user9540031 Member Posts: 222 Gold Badge

    The JDK included with the "64-bit with JDK" bundle was used in both cases, so for SQL Dev 21.4.3 that was 1.8.0_311-b11 for Windows 64-bit.

    Now, after switching to the JDK 11 bundled with 22.2.0, SQL Developer 21.4.3 appears just as slow!

    (Did I mention that this seems to make the IndexPreferencesTask very slow too?)

    Here goes the thread dump during the wait:

    (Attached as a plain text file, sorry, because the Forum software won't let paste it here.)

    Tested on Windows 7. I can do the same test on Windows 10 later if necessary.

    Thanks & Regards,

  • thatJeffSmith-Oracle
    thatJeffSmith-Oracle Distinguished Product Manager Posts: 8,687 Employee

    While not technically supported, you might want to try Java 17.

    Again, Windows 7 information is interesting, but not relevant. It's no longer supported by anyone, even Microsoft.

  • user9540031
    user9540031 Member Posts: 222 Gold Badge

    Again, Windows 7 information is interesting, but not relevant. It's no longer supported by anyone, even Microsoft.

    As an IT professional, I fully agree with you on this, I do—but the chief-computer-buyer-at-home in me has a different perspective about this inevitable upgrade; that's the contradiction.

    That said, here are the thread dumps from re-testing on Windows 10. They look strikingly similar—to me at least—so maybe you'll really have to believe me when I say they come from Windows 10.

    (But If you look at the following screenshot, you might recognize the subtly flatter looks of the GUI on Windows 10, though.)

    1. While waiting for the Save As dialog to open:

    • SQL Developer 21.4.3, with the bundled JDK 11 from 22.2.0
    • SQL Developer 22.2.0 with the bundled JDK 11

    2. While the (asynchronous, but slow) IndexPreferencesTask is running:

    • SQL Developer 21.4.3, with the bundled JDK 11 from 22.2.0
    • SQL Developer 22.2.0 with the bundled JDK 11

    Could the IndexPreferencesTask run abnormally long for the same reason? The top of the stack of the concerned thread looks the same.

    Regards,

  • user9540031
    user9540031 Member Posts: 222 Gold Badge

    you might want to try Java 17.

    I tried it, on Windows 10. Performance was similar to that of JDK 11.

    Here are the corresponding threads dumps.

    Regards,