> What kinda memory problems are you having? 30,000 > rows and 80 columns is 2.4 million cells which is > going to be a lot of memory. Do you run out of memory > anytime you try to display that many things? Or do > you run out of memory after several operations or your > program running for sometime?
I am having memory problems due to memory usage NOT going down. I have now written reflective disposal classes which I call on all my classes that remove all instances and listeners to the class, and all its associated members. It seems to be getting rid of most of my memory issues. > The former being a problem of using to much memory. > Where do you get the data from? Is it a database or > file? Currently they are just CSV files. I tried to use CSV files with 50-200,000+ rows but that wasn't working as I ran out of memory (with a -Xmx512m switch & heap equivalents). The JTable displays sweet as, its real quick and the performance is good. It is just when I close the panel (I am using my own subclass of jpanel which has a internal frame look) memory usage wasn't going down. I now have destroyed all the listeners and it seems to be working. I also found a cheap memory checker (www.jsprint.com) and it seems to find some memory leaks. > I have successfully displayed 50,000 rows in a > JTable before with good performance. I reduced a > considerable amount of memory usage by collapsing > duplicate uses of memory. When you read stuff out of > a database or file you can get lots of objects that > are value equivalent (.equals()), I collapsed those > references by passing all my data through a HashMap. > hashMapInstance.put( value, value ); Then retrieving > it again with hashMap.get( value ); That way all my > objects ended up collasping into one reference for > .equals(). I reduced my memory usage by 60%. Great idea, I didnt think of that. It will definitely speed up my system. Thanks heaps. > > If you think there is a leak, the later, then you'll > most definitely need a memory profiler. You can get a > 30 day trial license of OptimizeIT that's fully > functional. You won't be able to find all of them on > your own. Memory profiler is a must tool for Java. > > Try this, get OptimizeIT. Run your program, and look > at the instance graph. (The one with the counts of > instances, and red bars). Put a filter in at the > bottom of OptimizeIT so that it's just your classes > (i.e. net.my.program.*). Now look at what the number > one count of instances is. Is that more than you > expect? Now exercise the program in a way to make > some of those instances out of use, push the GC > button, and look at that instance count again. Did it > go down? If not, you got a leak. > > charlie > Cheers for the help. I will try what you said. > > One could reduce the memory footprint by > putting a layer between the TableCellRenderer > and the TableModel, which only fetches the > data for the currently displayed rows and > columns. I've done that with success. > Good idea also. Ill try to implement that as well. > 3. If you absolutely MUST have all rows in memory, have you considered > compressing the data in memory? You could use a zip class, or some other > third party product to compress your textual data in your objects, and only > decompress when the object is displayed. > Good idea. Ill try all three and see what works best. Thanks for all the help! Joe Cole _______________________________________________ Advanced-swing mailing list [EMAIL PROTECTED] http://eos.dk/mailman/listinfo/advanced-swing
