United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6557810 poor performance when using -splash option
6557810 : poor performance when using -splash option

Details
Type:
Bug
Submit Date:
2007-05-15
Status:
Closed
Updated Date:
2011-05-17
Project Name:
JDK
Resolved Date:
2011-05-17
Component:
client-libs
OS:
solaris_10
Sub-Component:
java.awt
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
7

Related Reports
Backport:
JDK-2187027 - poor performance when using -splash option
Relates:
JDK-6397447 - Splash screen (-splash:splash.png) + text drag = KDE/GNOME freeze
Relates:
JDK-6495729 - Splash screen: progress bar is very slow and lot of flickering in CDE

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Server VM (build 1.6.0_01-b06, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
SunOS sys1.nyc.deshaw.com 5.10 Generic_118855-31 i86pc i386 i86pc Solaris

A DESCRIPTION OF THE PROBLEM :
Applications perform more slowly when run with the -splash option, even after the splash screen goes away, or even when run with -splash:/dev/null.

The problem is especially noticeable when using a non-local X display.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile the attached code as TestTable.java.  Run it with and without the -splash option:

java -splash:/dev/null TestTable Splash
java TestTable NoSplash

  To see the effect, these should be run on a different machine than the one the X server is running on, so the X protocol has to actually go over the network.  Either setting DISPLAY directly or tunnelling with ssh -Y works.

Move the scroll bar on each window.  The one run with -splash is much slower.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I would expect both instances to run the same.
ACTUAL -
The one run with -splash runs much slower.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.*;
import javax.swing.*;
import javax.swing.table.*;

public class TestTable
{
    /**
     * @param args The number of rows to display in String form.
     */
    public static void main(String[] args)
    {
        if (args.length < 1) {
            System.err.println("args: <title>");
            System.exit(1);
        }

        JFrame frame = new JFrame(args[0]);
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

        TableModel tableModel = new TestTableModel(1000);
        JTable table = new JTable(tableModel);
        JScrollPane scrollPane = new JScrollPane(table);
        frame.getContentPane().add(scrollPane, BorderLayout.CENTER);
        frame.pack();
        frame.setVisible(true);
    }
}

/**
 * A simple TableModel which exists simply to generate rows for the test.
 */
class TestTableModel extends AbstractTableModel
{
    private int myRows;

    TestTableModel(int rows)
    {
        myRows = rows;
    }

    public int getRowCount()
    {
        return myRows;
    }

    public int getColumnCount()
    {
        return 10;
    }

    public Object getValueAt(int row, int column)
    {
        return new Integer(row * 10 + column);
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Don't use -splash.

Comments
EVALUATION

Actually, the SplashScreen code set the _Xdebug variable to 1 at the SplashInitPlatform() function at the src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c file. This caused the Xlib to operate in debug mode, and the debug mode is a synchronous mode. Hence, Xlib invoked the XSync() function after almost every X method invokation. The XSync() function actually generates the GetInputFocus request (that was observed. see the previous evaluation message). Eliminating the _Xdebug setting should considerably improve the performance of applications using the splash screen.
2007-07-25 
SUGGESTED FIX

$ sccs diffs -C splashscreen_sys.c

------- splashscreen_sys.c -------
*** /tmp/sccs.KYnARO    2007-07-25 13:48:32.000000000 +0400
--- splashscreen_sys.c  2007-07-25 13:48:22.000000000 +0400
***************
*** 392,398 ****
  SplashInitPlatform(Splash * splash) {
      int shapeVersionMajor, shapeVersionMinor;
  
!     _Xdebug = 1;
  
      pthread_mutex_init(&splash->lock, NULL);
  
--- 392,400 ----
  SplashInitPlatform(Splash * splash) {
      int shapeVersionMajor, shapeVersionMinor;
  
!     // This setting enables the synchronous Xlib mode! 
!     // Don't use it == 1 in production builds!
!     //_Xdebug = 1;
  
      pthread_mutex_init(&splash->lock, NULL);
2007-07-25 
EVALUATION

Using xmond I have noticed that when the application is ran with -splash:/dev/null option, lots of GetInputFocus X-server request are being generated. WHen there's no -splash option, there're much fewer such requests.
2007-07-05 
EVALUATION

When the application is ran with -splash option, the GetInputFocus request is being sent on every MouseMove. That seems to be the cause of the slowdown. However, putting a debug print into the XlibWrapper XGetInputFocus function does show nothing. It means that these requests are not generated via this method. Need to investigate a bit deeper the source of these requests.
2007-07-05 
EVALUATION

It's not easy to notice the performance drop, and ever more difficult to measure it. However, I was able to make both (approximately) by inserting some println statements. The new test file is attached.

I calculated the time between the start of main() method and the end of main() method and the first paint() method. Of course, this measurement doesn't reflect the time spent in splashscreen code before JVM started, however I can see some performance drop even after JVM is started.

Results on my desktop are the following:

----------------------------------------------------------------------------
                                  | w/ -splash option | w/o -splash option |
----------------------------------------------------------------------------
start of main() -> end of main()  | ~930 ms           | ~880 ms            |
start of main() -> first paint()  | ~1750 ms          | ~1450 ms           |
----------------------------------------------------------------------------
2007-05-18


Hardware and Software, Engineered to Work Together