Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #24407
| X-Received | by 10.224.200.202 with SMTP id ex10mr1557658qab.8.1371231724676; Fri, 14 Jun 2013 10:42:04 -0700 (PDT) |
|---|---|
| X-Received | by 10.50.36.41 with SMTP id n9mr223675igj.11.1371231724637; Fri, 14 Jun 2013 10:42:04 -0700 (PDT) |
| Path | csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!bw2no1702797qab.0!news-out.google.com!y6ni2876qax.0!nntp.google.com!j2no196418qak.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail |
| Newsgroups | comp.lang.java.programmer |
| Date | Fri, 14 Jun 2013 10:42:04 -0700 (PDT) |
| In-Reply-To | <kpf9i0$p3l$1@dont-email.me> |
| Complaints-To | groups-abuse@google.com |
| Injection-Info | glegroupsg2000goo.googlegroups.com; posting-host=69.28.149.29; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T |
| NNTP-Posting-Host | 69.28.149.29 |
| References | <9f2c5c11-c4e1-42bc-8c82-e0255ea897a5@m8g2000yqf.googlegroups.com> <kp89mi$uk$1@dont-email.me> <572d9ee8-aa0c-4275-a41c-e9bebccfbc21@googlegroups.com> <kpa3dh$5jo$1@dont-email.me> <a9e35bca-b530-49a0-94c4-fc920069e120@n13g2000yqj.googlegroups.com> <kpaash$j0h$1@dont-email.me> <429cccb8-27fb-4544-b560-461770aafb2c@v2g2000yqa.googlegroups.com> <kpf9i0$p3l$1@dont-email.me> |
| User-Agent | G2/1.0 |
| MIME-Version | 1.0 |
| Message-ID | <56efddbe-d2ff-45a0-a7ca-578c04e612f3@googlegroups.com> (permalink) |
| Subject | Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases |
| From | Lew <lewbloch@gmail.com> |
| Injection-Date | Fri, 14 Jun 2013 17:42:04 +0000 |
| Content-Type | text/plain; charset=ISO-8859-1 |
| Xref | csiph.com comp.lang.java.programmer:24407 |
Show key headers only | View raw
Eric Sosman wrote: > Haircuts Are Important wrote: >> Disregarding garbage collection, what do you think about "ever" using >> freeMemory() as an approximation for memory useage: > > > Runtime.getRuntime().gc(); Ha. >> long before = Runtime.getRuntime().freeMemory(); Long before what? >> long after = Runtime.getRuntime().freeMemory(); 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? -- Lew
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread
Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases Haircuts Are Important <clusardi2k@aol.com> - 2013-06-11 12:42 -0700
Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases Knute Johnson <nospam@knutejohnson.com> - 2013-06-11 15:56 -0700
Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases "John B. Matthews" <nospam@nospam.invalid> - 2013-06-11 22:51 -0400
Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases clusardi2k@aol.com - 2013-06-11 23:29 -0700
Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases clusardi2k@aol.com - 2013-06-11 23:35 -0700
Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases Haircuts Are Important <clusardi2k@aol.com> - 2013-06-12 05:11 -0700
Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-06-12 09:12 -0700
Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases Knute Johnson <nospam@knutejohnson.com> - 2013-06-12 08:21 -0700
Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases Haircuts Are Important <clusardi2k@aol.com> - 2013-06-12 09:13 -0700
Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-06-12 13:29 -0400
Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases Haircuts Are Important <clusardi2k@aol.com> - 2013-06-14 05:47 -0700
Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-06-14 10:37 -0400
Re: Memory & Pixel Usage Etc: As Number of JTable Rows & Columns Increases Lew <lewbloch@gmail.com> - 2013-06-14 10:42 -0700
csiph-web