This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

TableCellRenderer performance tuning problem

 
Steffen Foldager
Ranch Hand
Posts: 58
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
I have a JTable with a custom MainTableCellRenderer associated. The table is pretty big, and I want to optimize on the renderer. The expensive line is just above the return statement:

JProfiler (really cool tool by the way) shows me that the setText method in JLabel takes more than twice as much time as all the rest together. This is my bottleneck.
I've tried using java.awt.Label instead, which made matters a lot worse.
Any suggestions on how to further optimize this code?
Thanks,
Steffen
 
Chantal Ackermann
Ranch Hand
Posts: 508
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what exactly does the method value.toString()? is it the Object.toString method or did you overwrite it for a custom object? than you should look in that implementation?!
if your table is _really_ big you might improve performance by changing the loading behaviour of the scrollmode. I never did that myself but I've read about it.
see JViewport.setScrollMode(int) and
http://java.sun.com/products/jfc/tsc/articles/performance/index.html
cheers
 
Steffen Foldager
Ranch Hand
Posts: 58
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi c.
The toString() is the Object.toString(), but it isn't the problem. In some JProfiler sessions I had the last line on two:
String text = (value == null) ? "" : value.toString();
setText(text);
It is the JLabel.setText() method that is expensive.
The article is about scrolling, but my update problems happen when I'm selecting (mouseDown the mouseMoveAround..). Thanks anyway.
 
Chantal Ackermann
Ranch Hand
Posts: 508
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Steffen,
I have no suggestion but rather a question: Label.setText() is a very commonly used operation and I never heard of an application that had it as a bottleneck until now. So either the rest of you application is *really* fast or there is something in your render algorithm of JTable that slows down the setting of the text in the label.
I have a sample renderer in a book here that extends DefaultTableRenderer and uses the JLabel methods (setValue() e.g.) to change the appearance. maybe the DefaultTableCellRenderer does some things to speed up rendering (whith swing I could believe that).
cheers
 
Steffen Foldager
Ranch Hand
Posts: 58
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What are talking about? Off course I have a *really* *really" fast application
But thanks, you made me realize that I was implementing TableCellRenderer and not subclassing DefaultTableCellRenderer. So what's the difference? Wrt. performance it's quite big, so says the implementation note of DefaultTableCellRenderer (jdk 1.4).
This class inherits from JLabel, a standard component class. However JTable employs a unique mechanism for rendering its cells and therefore requires some slightly modified behavior from its cell renderer. The table class defines a single cell renderer and uses it as a as a rubber-stamp for rendering all cells in the table; it renders the first cell, changes the contents of that cell renderer, shifts the origin to the new location, re-draws it, and so on. The standard JLabel component was not designed to be used this way and we want to avoid triggering a revalidate each time the cell is drawn. This would greatly decrease performance because the revalidate message would be passed up the hierarchy of the container to determine whether any other components would be affected. So this class overrides the validate, revalidate, repaint, and firePropertyChange methods to be no-ops. If you write your own renderer, please keep this performance consideration in mind

So now I subclass DefaultTableCellRenderer instead, and the rendering of the cells is definitely more smooth. Problem solved! Case closed!
Steffen
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic