#1300 ✓closed
Al Dennis

Use less memory

Reported by Al Dennis | October 24th, 2010 @ 02:41 PM | in Features

I like to keep around finished auctions so that I can refer back to them. So, now I have about 1000. This causes jbidwatcher to use lots of ram.

So I poked around a bit with a heap-analysis tool (jhat) and came up with the attached patch to reduce memory usage.

It addresses a couple things - places where a constant DateFormat was an instance field instead of static, and some constant strings (often keys in hashtables) that get newly-created too much.

DateFormat.format() should generally be in a synch block, as it's not thread-safe. So where I made the DateFormat field static, I also rejigged calls to format().


Comments and changes to this ticket

  • Therese Telepski

    Therese Telepski October 25th, 2010 @ 01:49 PM


    JBW was never intended as a 'big' database to do mining on all of your past auctions.

    If you're really interested in it a much better solution would be exporting the ended auctions on a regularly bases and put them into a database of your choice -- thus allowing for all kind of sorting, filtering, selecting, reporting etc. After successfully exporting them you should delete them from the completed tab of JBW and then run 'Clear deleted tracking' from the file menu.



  • Christoph Franzen

    Christoph Franzen October 26th, 2010 @ 07:02 PM


    saving memory is nonetheless a good thing. It is also likely to improve speed if the unnecessary recreation of data structures is avoided.


  • Morgan Schweers

    Morgan Schweers October 27th, 2010 @ 03:42 AM

    • State changed from “new” to “open”
    • Milestone set to Features
    • Tag set to feature
    • Milestone order changed from “234” to “0”

    I'll certainly take a look at it.

    I'm happy to clean up memory usage wherever possible; I know I've made a few 'quick' changes recently which might be increasing it.

    The real answer, though, is to not keep non-'updating' auctions in memory, but dynamically load them from the database as needed. (I.e. the entire 'completed' tab shouldn't be in memory if you're not looking at it.)

    That's my long-term goal and answer to memory issues...

    -- Morgan Schweers, CyberFOX!

  • Morgan Schweers

    Morgan Schweers October 27th, 2010 @ 03:59 AM

    So...for future reference, Strings in Java are immutable and compile-time strings are interned, which is to say that all references to the same string at compile time refer to the same object in memory at runtime. This means that the infoTags changes and all the one-word private final static Strings you added at the top of AuctionEntry (for example) won't actually change anything. Those aren't new strings created per-instance; they're already the same string, referenced by multiple instances.

    Most of the DateFormat stuff is okay, but all the string changes won't do anything for the program.

    Thanks muchly for the code! It's very rare that anybody contributes code, and I'm really happy to see it...

    I can poke at extricating the DateFormat changes at some point, or you could redo it without the String tweaks, and resubmit it... Optimally if you clone the cyberfox/jbidwatcher project on GitHub, make the changes, and send me a pull request, I can really easily bring it into the JBidwatcher codebase, and it preserves authorship and everything.

    -- Morgan Schweers, CyberFOX!

  • Morgan Schweers

    Morgan Schweers March 8th, 2017 @ 04:39 PM

    • State changed from “open” to “closed”
    • Tag changed from feature to feature, old

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Shared Ticket Bins

People watching this ticket