Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases

  • Thread starter Haircuts Are Important
  • Start date
H

Haircuts Are Important

How much memory does a JTable use as the number of rows and columns in
increases.

How can I measure memory useage and number of pixels used by a JTable.

Thank you,
 
K

Knute Johnson

How much memory does a JTable use as the number of rows and columns in
increases.

How can I measure memory useage and number of pixels used by a JTable.

Thank you,

As to memory I have no idea but I am curious why it matters. Most
modern computers have a boat load of memory and virtual memory. As for
pixels, you can create it, display it on a JPanel, pack it and ask it
how big it is.
 
J

John B. Matthews

Knute Johnson said:
As to memory I have no idea but I am curious why it matters.
Most modern computers have a boat load of memory and virtual
memory. As for pixels, you can create it, display it on a
JPanel, pack it and ask it how big it is.

Knute's right: Because JTable uses the flyweight pattern to render
cells, it's memory footprint scales with the number of visible
cells. The rest depends on the data structure that underlies your
TablelModel. Profile to be sure.

You've asked about this before, in a now deleted question:

<https://groups.google.com/forum/?fromgroups&hl=en#!topic/comp.lang.java.programmer/CjA3KBqjvVs>
 
C

clusardi2k

On 6/11/2013 12:42 PM, Haircuts Are Important wrote: > How much
memory does a JTable use as the number of rows and columns in >
increases. > > How can I measure memory useage and number of pixels
used by a JTable. > > Thank you, > As to memory I have no idea but
I am curious why it matters. Most modern computers have a boat load
of memory and virtual memory. As for pixels, you can create it,
display it on a JPanel, pack it and ask it how big it is. -- Knute Johnson
 
C

clusardi2k

On 6/11/2013 12:42 PM, Haircuts Are Important wrote: > How much
memory does a JTable use as the number of rows and columns in >
increases. > > How can I measure memory useage and number of pixels
used by a JTable. > > Thank you, > As to memory I have no idea but
I am curious why it matters. Most modern computers have a boat load
of memory and virtual memory. As for pixels, you can create it,
display it on a JPanel, pack it and ask it how big it is. -- Knute
Johnson

It matters to me because of overall efficiency questions. Basically, if I have many other programs running or computationally intense prgrams running at the same time will my new java project slow all these programs down if it has many rows and columns. Can I improve the effiency more by restrictingmy new project to only a few rows and columns.

Thanks,
 
H

Haircuts Are Important

It matters to me because of overall efficiency questions. Basically, if Ihave many other programs running or computationally intense prgrams running at the same time will my new java project slow all these programs down ifit has many rows and columns. Can I improve the effiency more by restricting my new project to only a few rows and columns.

Thanks,

Does java have something like the old "sizeof" function in the
language C.
 
K

Knute Johnson

It matters to me because of overall efficiency questions. Basically,
if I have many other programs running or computationally intense
prgrams running at the same time will my new java project slow all
these programs down if it has many rows and columns. Can I improve
the effiency more by restricting my new project to only a few rows
and columns.

Thanks,

It's not an answerable question. Speed is relative to the amount of
memory, processor and video card resources available divided by the load.

How many elements does your JTable have?
 
D

Daniel Pitts

Does java have something like the old "sizeof" function in the
language C.
No.

The JTable itself won't add a lot of extra memory usage, most of the
usage will likely come from your data itself.

Even if you had sizeof, the best way to determine the actual efficiency
of a program is by testing and profiling.

If you're thinking on the scale of a few hundred, I wouldn't even worry
about it. tens of thousands I'd start to get a little concerned, but
I'd test first.

No easy answer, you just gotta fill your data structure and see what
happens.
 
H

Haircuts Are Important

It's not an answerable question.  Speed is relative to the amount of
memory, processor and video card resources available divided by the load.

How many elements does your JTable have?

The main JTable has only m rows and n columns with each cell
consisting of alphanumeric data of 10 characters or less.
 
E

Eric Sosman

[...]
How many elements does your JTable have?

The main JTable has only m rows and n columns with each cell
consisting of alphanumeric data of 10 characters or less.

Set m=0 or n=0 (or both), and your memory problems will be over.
Wasn't that simple?
 
H

Haircuts Are Important

Disregarding garbage collection, what do you think about "ever" using
freeMemory() as an approximation for memory useage:

Runtime.getRuntime().gc();
long before = Runtime.getRuntime().freeMemory();
long after = Runtime.getRuntime().freeMemory();

Thanks,
 
E

Eric Sosman

Disregarding garbage collection, what do you think about "ever" using
freeMemory() as an approximation for memory useage:

Runtime.getRuntime().gc();
long before = Runtime.getRuntime().freeMemory();
long after = Runtime.getRuntime().freeMemory();

"Disregarding garbage collection," freeMemory() is a reliable
way to measure a meaningless quantity. Disregarding gravity, how
high can you jump?

It's possible to use totalMemory() and freeMemory() and a lot
of care (calling gc() "suggests" garbage collection and promises
only a "best effort") to estimate the sizes of simple objects like
Integers, fixed-length Strings or arrays, and so on. But with more
complex objects containing references to other complex objects it
becomes much more difficult. You seem to be concerned about how
much memory a JTable uses -- well, does that include the TableModel?
The data in the TableModel? The TableColumnModel, the internal
HashTables that store editors and renderers, the editors and
renderers themselves, ...? You've got a fairly thorny definitional
problem before you can even get started.

Ah, the heck with it. Here's the output of a micro-benchmark
I wrote some time ago, estimating the size of a `new JTable()' by
fitting least-squares lines relating "instance count" to "heap used:"

500 instances: 5247.664 bytes each
1000 instances: 5248.128 bytes each
1500 instances: 5220.9584 bytes each
2000 instances: 5220.9328 bytes each
2500 instances: 5224.7922285714285 bytes each
3000 instances: 5228.693142857142 bytes each
3500 instances: 5231.899428571429 bytes each
4000 instances: 5234.469066666667 bytes each
4500 instances: 5236.533624242425 bytes each
5000 instances: 5238.165672727273 bytes each
BUILD SUCCESSFUL (total time: 14 seconds)

There you have it -- but *what* do you have?
 
L

Lew

Eric said:

Long before what?

Long after what?
"Disregarding garbage collection," freeMemory() is a reliable
way to measure a meaningless quantity. Disregarding gravity, how
high can you jump?

It's possible to use totalMemory() and freeMemory() and a lot
of care (calling gc() "suggests" garbage collection and promises
only a "best effort") to estimate the sizes of simple objects like
Integers, fixed-length Strings or arrays, and so on. But with more
complex objects containing references to other complex objects it
becomes much more difficult. You seem to be concerned about how
much memory a JTable uses -- well, does that include the TableModel?
The data in the TableModel? The TableColumnModel, the internal
HashTables that store editors and renderers, the editors and
renderers themselves, ...? You've got a fairly thorny definitional
problem before you can even get started.

Ah, the heck with it. Here's the output of a micro-benchmark
I wrote some time ago, estimating the size of a `new JTable()' by
fitting least-squares lines relating "instance count" to "heap used:"

500 instances: 5247.664 bytes each
1000 instances: 5248.128 bytes each
1500 instances: 5220.9584 bytes each
2000 instances: 5220.9328 bytes each
2500 instances: 5224.7922285714285 bytes each
3000 instances: 5228.693142857142 bytes each
3500 instances: 5231.899428571429 bytes each
4000 instances: 5234.469066666667 bytes each
4500 instances: 5236.533624242425 bytes each
5000 instances: 5238.165672727273 bytes each
BUILD SUCCESSFUL (total time: 14 seconds)

There you have it -- but *what* do you have?

A meaningless benchmark of a meaningless quantity that lacks predictive value.

As you point out. Complicated by the fact that the same structure in a program
can occupy not just somewhat different amounts of memory, as you show, but
wildly different amounts. Optimization can remove an object from heap altogether
under certain circumstances, circumstances that can change during program execution
and cause that same structure to occupy heap at other times.

That is over 100% reduction in size, depending on which of the "in-heap" memory
numbers you use as 100%.

And "Haircuts", for God's sake stop deleting your posts. What in the heck is wrong with you?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top