8 Replies Latest reply: Apr 8, 2014 8:55 AM by Henk Boerboom RSS

    4.0.1.14 very slow in saving files

    Henk Boerboom

      On my Win XP machine it takes 5 seconds to save a file of 1k or 500k to my internal drive.

      On the network drive 6 seconds for 1k and 30 seconds for 500k

      Save a file means: Top menu> File> Save (as in a open SQL-script in a tab)

      I think it has to do with the SQL Worksheet/History and the Revisions that are Local.

       

      In 3.1.07 all the above takes a fraction of a second.

        • 1. Re: 4.0.1.14 very slow in saving files
          rp0428

          What does 'save a file' mean to you?

           

          Are you talking about saving the data in a data grid?

           

          Are you talking about exporting data from a table to a file directly?

           

          If using a data grid confirm that:

           

          1. The grid setting for number of rows filter is set the same for both versions.

           

          2. You have first navigated to the END of the data. Only a portion of the data is retrieved at a time based on the filter setting. If all of the data hasn't been retrieved yet any delay could just be Oracle or the network delay as the rest of the data is fetched.

          • 2. Re: 4.0.1.14 very slow in saving files
            Henk Boerboom

            Save a file means: Top menu> File> Save (as in a open SQL-script in a tab)

            • 3. Re: 4.0.1.14 very slow in saving files
              rp0428
              Save a file means: Top menu> File> Save (as in a open SQL-script in a tab)

              Works fine for me in that same version on XP SP3.

               

              Paste a 30k file from the clipboard to a script window and 'File > Save' saves it immediately.

              • 4. Re: 4.0.1.14 very slow in saving files
                Henk Boerboom

                Hi RP, I also have XP SP3.

                Your test case also works fine on my PC.

                When I use 'Save As' it also saves it immediately.

                 

                So now I think it has to do with the SQL Worksheet/History and the Revisions that are Local.

                Preferences> Environment> History> are 7 days and 50 versions, the same as in SQLDev3

                 

                In SQLDev3 there is a button to 'Purge Local History' but in SQLDev4 it is not there anymore.

                 

                Q: Where are the Revisions kept ?

                • 5. Re: 4.0.1.14 very slow in saving files
                  Gary Graham-Oracle

                  Henk,

                  For the location of local worksheet history, look in your user settings .history folder under the systemN.N.N.N.N folder.  So...

                  Windows XP:     C:\Documents and Settings\<user-name>\Application Data\SQL Developer\system4.0.1.14.48\.history

                  Windows 7:       C:\Users\<user-name>\AppData\Roaming\SQL Developer\system4.0.1.14.48\.history

                  This link to the 4.0 Installation Guide also includes the location of user-related information for other operating systems:

                  Installing Oracle SQL Developer

                   

                  As to the performance issue, it could be any number of things.  From my experience testing (unrealistically) large files, it could be something as simple as the script parser running in the background, doing its job, but eating up huge amounts of memory in the Java VM and triggering garbage collection.  This causes SQL Developer to slow down and eventually become unresponsive.  Changing Code Editor preferences for Completion Insight and Display (Show Breadcrumbs) may help.  You might also review the size of your regular SQL History.

                   

                  Regards,
                  Gary

                  SQL Developer Team

                  • 6. Re: 4.0.1.14 very slow in saving files
                    Henk Boerboom

                    Gary, I found the history  .. in my redericted user-directory. that's why I couldn't find them earlier.

                    Now that they are on a (slow) server, that is not helping the performance.

                    I tested the Code Editor preferences, but the performance didn't change.

                     

                    As for JavaVM, I don't see a java.exe appearing in the tasks, as I see for some websites.

                    Or I am looking in the wrong place ?

                    {After installation I removed JRE7 because I need JRE6u16 for eBS 12.1.3, told SQKDev4 where to find JDK7u51}

                    As for SQLDev4: adding 1 letter and deleting it costs 4Mb memory and saving the file adds 1Mb. Closing the file doesn't release any memmory, but takes another 3Mb.

                    • 7. Re: 4.0.1.14 very slow in saving files
                      Gary Graham-Oracle

                      Henk,

                      If you believe the primary reason for poor performance is redirecting (locating) the user-directory to a slow server over a slow/high latency network, then consider adding the following line to your ...\sqldeveloper\sqldeveloper\bin\sqldeveloper.conf:

                      AddVMOption -Dide.user.dir=<path-specification-to-local-directory-for-sqldev-user-settings>

                      First, of course, exit SQL Developer, copy over your current settings, then relaunch SQL Developer.  If you somehow manage to launch the product directly from java on the command line or via a custom bat file, Task Manager's process tab will show the name as java.exe.  Launching via one of the sqldeveloper* exe files, however, will always show the name of the exe.

                       

                      With regard to Task Manager and virtual storage reporting, the value displayed has more to do with JVM total memory allocation (used + free) plus something extra for Windows.  Reflecting freed memory after closing a file or closing a connection is more a function of the JVM garbage collection algorithm.  Apparently the one called G1 (Garbage-First) is more likely to deallocate memory so Task Manage actually displays a reduced value.  You can read about it if you like: Java HotSpot Garbage Collection

                       

                      -Gary-

                      • 8. Re: 4.0.1.14 very slow in saving files
                        Henk Boerboom

                        Hi Gary, this does the trick for me right now. Saving a large file (log-file ) is instant.

                        {and I copied the files from ...\Application Data\SQL Developer\system4.0.1.14.48, to my hard-drive directory}

                        {btw: saving a small 1k-file took 5 seconds}

                         

                        But it does not explain why this behaviour shows in SQLDev4..0.1.14.48.

                        In my SQLDev3 installation the saves are instant on the same large file and the history is also on the same network-drive:

                        ...\Application Data\SQL Developer\system3.1.07.42\.history

                         

                        Thanks for the quick replies.