• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Creating lots of BigDecimal objects in a loop - concerns about memory

 
Ranch Hand
Posts: 31
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I am writing a program which works with epoch timestamps out of log files. There is a part of the program in which I am iterating through these timestamps, trying to find the first after a threshold, and since it is very important that there aren't any number representation errors, I would like to store the time read in as a BigDecimal object, initialised from the string in the file (unfortunately I can't use longs to store the time as the format of the string is <digits>.<digits> seconds).

The immutability of BigDecimal objects poses a problem, as, since I am checking each timestamp in turn and there is very little logic in each loop iteration, I would be creating a huge number of BigDecimal objects, and the program may in the future be extended for concurrent execution, such that many files would be processed at once. I'm therefore worried about the memory footprint of the method described.

I was initially wondering if there's a way to deallocate memory for objects in Java, such that I could deallocate the previous BigDecimal object each time I created a new one, but there doesn't seem to be. The closest I seem to be able to get is being able to request garbage collection, but will that be fast enough to offset the rate at which new BigDecimal objects are being created, and is it a bad idea to perform the request as often as in a for loop which is executed hundreds or thousands of times each second?

If anyone has any suggestions for reading in the time from the file so that it can be compared without loss of accuracy due to number representation I would be only too happy to receive them

Many thanks.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Advice: don't tune performance based on gut feelings.  Use a profiler to see if you really have a problem. If you declare your BigDecimal as a local variable and just replace it with each new value you need to check, I don't see why you'd need to worry about memory usage or concurrency. Local variables are inherently thread safe and since the BigDecimal is immutable, that's double protection against concurrency problems.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are some who say that you should actually allocate a smaller amount of memory to your JVM in that case, otherwise the application is going to pause periodically while the JVM collects a huge amount of garbage. But that only makes a difference if there's somebody physically sitting there who is going to be annoyed or inconvenienced by large but infrequent garbage collection events. I suspect that you just want your application to finish in a reasonable amount of time without crashing, in which case it probably doesn't make any difference. Creating a large number of short-lived objects won't cause your application to run out of memory, but you might be concerned about how long it takes to run.

If you find you do care about that, then you could tinker with garbage-collection parameters and JVM memory allocations and you might find that you can improve the elapsed time for the application to run. But don't bother with that until you decide that you really do care.
 
reply
    Bookmark Topic Watch Topic
  • New Topic