JLabels Are Big

[Jason Cavett]

I'm currently in the process of creating a "tokenized" panel where a
formula can be displayed on that panel and the user can select
different tokens and add/remove them.

Currently, I am using a JPanel and I'm using a JLabel to display and
draw the formula text. (One JLabel per token.) The problem I am
noticing is that JLabels chew up memory. If 20 or more tokens are
created (which is quite possible given the functionality of the
application), memory starts loading up and the application bogs down.

Does anybody have any alternative suggestions to using a JPanel w/
JLabels. So far I have come up with:

1. Write my own "JLabels" that only provide the functionality I need.
The problem is, it seems that a lot of the extra crap comes from
Component, JComponent, etc (all the stuff that JLabel needs to draw
itself). So, I'm not sure this idea would help anything.

2. I could also write a JPanel of sorts and have it render its text
directly in the panel rather than through the JLabels. Then, when the
user clicked the JPanel, I would have to do the work to check where
the selection is taking place and do all the drawing for line
wrapping, selection, key and mouse listeners, etc, etc. This would
definitely make things more lightweight in terms of memory, but I'm
not sure that this is the best way to go due to the time involved.

If anybody has any additional suggestions, I'd appreciate it.
Basically, I need to not use as much memory with the JLabels.


Thanks

 

[Daniel Pitts]

I'm currently in the process of creating a "tokenized" panel where a
formula can be displayed on that panel and the user can select
different tokens and add/remove them.

Currently, I am using a JPanel and I'm using a JLabel to display and
draw the formula text. (One JLabel per token.) The problem I am
noticing is that JLabels chew up memory. If 20 or more tokens are
created (which is quite possible given the functionality of the
application), memory starts loading up and the application bogs down.

20 sounds like a reasonable number of labels. Are you sure the memory is
being chewed up by the labels? Have you run a memory profiler to
determine this?

Does anybody have any alternative suggestions to using a JPanel w/
JLabels. So far I have come up with:

1. Write my own "JLabels" that only provide the functionality I need.
The problem is, it seems that a lot of the extra crap comes from
Component, JComponent, etc (all the stuff that JLabel needs to draw
itself). So, I'm not sure this idea would help anything.

2. I could also write a JPanel of sorts and have it render its text
directly in the panel rather than through the JLabels. Then, when the
user clicked the JPanel, I would have to do the work to check where
the selection is taking place and do all the drawing for line
wrapping, selection, key and mouse listeners, etc, etc. This would
definitely make things more lightweight in terms of memory, but I'm
not sure that this is the best way to go due to the time involved.

If anybody has any additional suggestions, I'd appreciate it.
Basically, I need to not use as much memory with the JLabels.

JLabels don't generally use *that* much memory, I think perhaps there is
some other issue in your program.

Thanks

Good luck,
Daniel.

 

[Mark Space]

noticing is that JLabels chew up memory. If 20 or more tokens are
created (which is quite possible given the functionality of the
application), memory starts loading up and the application bogs down.

I agree with Daniel, 20 labels is not a lot. You likely have some other
resource issue here. Better fix that first.

2. I could also write a JPanel of sorts and have it render its text
directly in the panel rather than through the JLabels. Then, when the
user clicked the JPanel, I would have to do the work to check where

This is more or less what I would do. Create your own
java.awt.Component that just displays what you want. You might be able
to subclass Image and then just draw the formula with Graphics2D
operations, and then update in the usual way for Images.

However, you might check out JEditorPane. It might be possible to
compose your formula in HTML, and then just use setText. HTML also
might be more portable. JEditorPanes are already editable, so you might
be able to leverage that instead of do the all the code for editing from
mouse click and keyboard presses yourself.

 

[Roedy Green]

Does anybody have any alternative suggestions to using a JPanel w/
JLabels. So far I have come up with:

This is a trick I learned back in the jdk 1.0 days for speed.

You created JPanel like Component that you draw the labels on
yourself. You calculate the x,y and use Drawstring, and perhaps some
other fancy decoration.

When you get a mouseclick you divide x by label width and y by label
height to get the label grid indexes.

 

[Jason Cavett]

I agree with Daniel, 20 labels is not a lot.  You likely have some other
resource issue here.  Better fix that first.


This is more or less what I would do.  Create your own
java.awt.Component that just displays what you want.  You might be able
to subclass Image and then just draw the formula with Graphics2D
operations, and then update in the usual way for Images.

However, you might check out JEditorPane.  It might be possible to
compose your formula in HTML, and then just use setText.  HTML also
might be more portable.  JEditorPanes are already editable, so you might
be able to leverage that instead of do the all the code for editing from
mouse click and keyboard presses yourself.

I did a little more research. As you have said, 20 labels isn't big
and doesn't really affect anything. But, when I get upwards of 100+
labels, I notice a pretty big slowdown. Even then, my JLabels are
~419 bytes in size and, while that is somewhat big, it's not THAT big.

I guess I'll start doing some memory profiling to find out where
memory is being used up and what's causing the problem.

 

[Mark Space]

I did a little more research. As you have said, 20 labels isn't big
and doesn't really affect anything. But, when I get upwards of 100+
labels, I notice a pretty big slowdown. Even then, my JLabels are
~419 bytes in size and, while that is somewhat big, it's not THAT big.

I guess I'll start doing some memory profiling to find out where
memory is being used up and what's causing the problem.

You may have lots of previously made objects (labels) laying around
taking up memory, and the gc is thrashing trying to find new memory to
allocate. If something is holding a reference to those old labels,
they'll not be available for garbage collection.

When you profile, turn on both object creation and garbage collection
monitoring (under "Memory"). That way you'll have the data you need.
I'd also turn on Thread Monitoring (under "Monitor") because it sounds a
bit more like you have a run-away thread or something.

Look at the "generations" column of the memory allocation display.
Objects that survive many generations of garbage collection are possibly
leaking. If you should have 100 labels but there are 10,000 in memory
being held, you definitely have some sort of leak. Looking at the
generation number might help you figure out where the leak is. You may
have to turn on stack tracing for object creation to figure out exactly
where this is.

 

[Jason Cavett]

You may have lots of previously made objects (labels) laying around
taking up memory, and the gc is thrashing trying to find new memory to
allocate.  If something is holding a reference to those old labels,
they'll not be available for garbage collection.

When you profile, turn on both object creation and garbage collection
monitoring (under "Memory").  That way you'll have the data you need.
I'd also turn on Thread Monitoring (under "Monitor") because it sounds a
bit more like you have a run-away thread or something.

Look at the "generations" column of the memory allocation display.
Objects that survive many generations of garbage collection are possibly
leaking.  If you should have 100 labels but there are 10,000 in memory
being held, you definitely have some sort of leak.  Looking at the
generation number might help you figure out where the leak is.  You may
have to turn on stack tracing for object creation to figure out exactly
where this is.

I'm assuming you're looking at the hprof tool that is supplied with
the JVM? (Just making sure.)

 

[Mark Space]

I'm assuming you're looking at the hprof tool that is supplied with
the JVM? (Just making sure.)

Actually I'm looking at the profiler in NetBeans.

Take a look at this, see if it looks like something you'd like to use.
NetBeans is an easy download, and you can import any project just by
pointing it at the build script and the source file tree.

http://www.netbeans.org/kb/60/java/profiler-intro.html

Sorry about that, I just assumed you were using an IDE.

 

[Jason Cavett]

Actually I'm looking at the profiler in NetBeans.

Take a look at this, see if it looks like something you'd like to use.
NetBeans is an easy download, and you can import any project just by
pointing it at the build script and the source file tree.

http://www.netbeans.org/kb/60/java/profiler-intro.html

Sorry about that, I just assumed you were using an IDE.

No problem. I am using an IDE - Eclipse. I'll look to see what sort
of profiling tools Eclipse may have. If not, I'll check out Netbeans.

Thank you for the detailed description on the Netbeans profiling tool.

 

[Mark Space]

No problem. I am using an IDE - Eclipse. I'll look to see what sort
of profiling tools Eclipse may have. If not, I'll check out Netbeans.

Thank you for the detailed description on the Netbeans profiling tool.

I don't mean to start any editor wars. I'm sure Eclipse has similar, if
not identical, capability. I think NetBeans uses JMX so I its reporting
would be exactly the same as any other tool.

Please do report back what you find in Eclipse. I'm not up to speed on
it, and I'd love to have some info at my finger tips when I start to
work on it more earnestly.