coding trick to reduce number of small objects generated

Discussion in 'Java' started by Roedy Green, Aug 4, 2005.

  1. Roedy Green

    Roedy Green Guest

    I was reading a book called Java Platform Performance, Strategies and
    Tactics.

    It pointed out the bottleneck often turns out to be creating zillions
    of tiny objects. The author was on the Swing team profiling it to
    reduce the number of objects generated.

    That is why Swing Renderers reuse the same Component over and over.

    Anyway, consider a method LIKE getSize that returns a Dimension
    object.

    getSize creates a new Dimension object every time so that if the user
    screws with the fields, it won't affect anyone else.

    Ah ha you say. Why not invent an immutable Dimension object, then you
    can safely return the same copy to everyone?

    Well, what if you want to change the value and have everyone informed
    who has taken a reference to the immutable object?

    you can SUBCLASS the immutable object adding setter methods. You
    return an reference to the "immutable" object, but you set it with the
    mutable object reference.

    Now the sneaky user could subvert you by casting to the mutable
    version. Unfortunately, you can't hide the mutable version. You can't
    restrict access when you subclass.

    --
    Bush crime family lost/embezzled $3 trillion from Pentagon.
    Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
    http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

    Canadian Mind Products, Roedy Green.
    See http://mindprod.com/iraq.html photos of Bush's war crimes
     
    Roedy Green, Aug 4, 2005
    #1
    1. Advertising

  2. Roedy Green wrote:
    >
    > Ah ha you say. Why not invent an immutable Dimension object, then you
    > can safely return the same copy to everyone?


    If you wanted the clients informed, you'd have to add a listener type
    set up. Not cheap.

    Dimension is pretty much useless for manipulating. The vast majority of
    the time it is used as a return argument. If it had been immutable in
    the sense of immutable, it wouldn't sap as much performance and wouldn't
    require cloning code everywhere.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Aug 4, 2005
    #2
    1. Advertising

  3. "Thomas Hawtin" <> wrote in message
    news:42f1560e$0$24049$...
    > Roedy Green wrote:
    >>
    >> Ah ha you say. Why not invent an immutable Dimension object, then you
    >> can safely return the same copy to everyone?

    >
    > If you wanted the clients informed, you'd have to add a listener type set
    > up. Not cheap.
    >
    > Dimension is pretty much useless for manipulating. The vast majority of
    > the time it is used as a return argument. If it had been immutable in the
    > sense of immutable, it wouldn't sap as much performance and wouldn't
    > require cloning code everywhere.
    >



    Yes. Block makes exactly this point in _Effective Java_.
     
    Mike Schilling, Aug 4, 2005
    #3
  4. Roedy Green

    jan V Guest

    Also see Flyweight design pattern in GoF book....
     
    jan V, Aug 4, 2005
    #4
  5. Roedy Green

    Filip Larsen Guest

    Roedy Green wrote

    > Anyway, consider a method LIKE getSize that returns a Dimension
    > object.
    >
    > getSize creates a new Dimension object every time so that if the user
    > screws with the fields, it won't affect anyone else.
    >
    > Ah ha you say. Why not invent an immutable Dimension object, then you
    > can safely return the same copy to everyone?


    If the type returned is defined by an interface you can also return a
    fixed reference to a read-only proxy for the real value. If the returned
    type also is a bean it should be possible to use general code to
    generates the read-only proxy.

    Another option I often use for values like Dimension is to provide an
    additional getter method that takes an out-parameter. Code in a tight
    loop can then choose to call this getter with the same instance over and
    over if needed for performance, while non-critical code can continue to
    use the traditional getter for clarity and conformance to style.


    Regards,
    --
    Filip Larsen
     
    Filip Larsen, Aug 4, 2005
    #5
  6. Roedy Green

    Roedy Green Guest

    On Thu, 04 Aug 2005 03:12:39 GMT, "Mike Schilling"
    <> wrote or quoted :

    >> Dimension is pretty much useless for manipulating. The vast majority of
    >> the time it is used as a return argument. If it had been immutable in the
    >> sense of immutable, it wouldn't sap as much performance and wouldn't
    >> require cloning code everywhere.


    You would still have to create a new one every time the dimensions
    changed, but presumably that is much less often than you query the
    dimensions.

    --
    Bush crime family lost/embezzled $3 trillion from Pentagon.
    Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
    http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

    Canadian Mind Products, Roedy Green.
    See http://mindprod.com/iraq.html photos of Bush's war crimes
     
    Roedy Green, Aug 5, 2005
    #6
  7. Roedy Green

    John Currier Guest

    Thomas Hawtin wrote:
    > Roedy Green wrote:
    > >
    > > Ah ha you say. Why not invent an immutable Dimension object, then you
    > > can safely return the same copy to everyone?

    >
    > If you wanted the clients informed, you'd have to add a listener type
    > set up. Not cheap.
    >
    > Dimension is pretty much useless for manipulating. The vast majority of
    > the time it is used as a return argument. If it had been immutable in
    > the sense of immutable, it wouldn't sap as much performance and wouldn't
    > require cloning code everywhere.


    Have you guys ever developed in C++? I often long for const in Java,
    especially when I have to do this type of cloning to prevent users from
    modifying my data.

    John
    http://schemaspy.sourceforge.net
     
    John Currier, Aug 5, 2005
    #7
  8. John Currier wrote:
    > Thomas Hawtin wrote:
    >
    > Have you guys ever developed in C++? I often long for const in Java,
    > especially when I have to do this type of cloning to prevent users from
    > modifying my data.


    Yup. Sounds like you're still writing C++ in Java.

    A const object in C++ can still change. What a nightmare. Returning an
    internal implementation object as const is not nice. It exposes
    implementation and pegs lifetime and state of object and return value
    together.

    To get around these in C++ problems you have features such implicit
    copying, destructors, smart pointers, etc. Wart on top of wart on top of
    wart.

    If you program Java in Java then you'll make simple value types like
    Dimension immutable. Problem solved.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Aug 5, 2005
    #8
  9. Roedy Green wrote:
    >
    > You would still have to create a new one every time the dimensions
    > changed, but presumably that is much less often than you query the
    > dimensions.


    Yup. The number of times layout are validated while most of the
    components don't change size is frightening.

    You can cache small immutable objects, but it's hardly worthwhile and
    may cause hidden performance issues. Not that the time allocation time
    is very long (I measured around 30-40 cycles/100-150 ns on my old PII).

    http://jroller.com/page/tackline?entry=fast_immutables

    Tom Hawtin

    (Just a reminded: immutable are not worth caching.)
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Aug 5, 2005
    #9
  10. Thomas Hawtin wrote:
    > John Currier wrote:
    >
    >> Thomas Hawtin wrote:
    >>
    >> Have you guys ever developed in C++? I often long for const in Java,
    >> especially when I have to do this type of cloning to prevent users from
    >> modifying my data.

    >
    >
    > Yup. Sounds like you're still writing C++ in Java.
    >
    > A const object in C++ can still change. What a nightmare.


    Yes, but you can reasonably represent that code that attempts to modify
    a const object is a bug. (Presumably this is third-party client code,
    using your library.)

    > Returning an
    > internal implementation object as const is not nice. It exposes
    > implementation and pegs lifetime and state of object and return value
    > together.


    I do not see how the the last comment is specific to C++. So it fails
    to explain the first comment to me.

    >
    > To get around these in C++ problems you have features such implicit
    > copying, destructors, smart pointers, etc. Wart on top of wart on top of
    > wart.
    >
    > If you program Java in Java then you'll make simple value types like
    > Dimension immutable. Problem solved.


    And different problems created; which is the subject of this thread.
    Also, Java-style immutable objects can be created in C++ uses the same
    techniques.

    >
    > Tom Hawtin


    Ray

    --
    XML is the programmer's duct tape.
     
    Raymond DeCampo, Aug 5, 2005
    #10
  11. Roedy Green

    Roedy Green Guest

    On 4 Aug 2005 20:59:15 -0700, "John Currier" <>
    wrote or quoted :

    >Have you guys ever developed in C++? I often long for const in Java,
    >especially when I have to do this type of cloning to prevent users from
    >modifying my data.


    The problem with const in C++ is not everyone understands it and end
    up bypassing your safety.

    --
    Bush crime family lost/embezzled $3 trillion from Pentagon.
    Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
    http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

    Canadian Mind Products, Roedy Green.
    See http://mindprod.com/iraq.html photos of Bush's war crimes
     
    Roedy Green, Aug 5, 2005
    #11
  12. Roedy Green

    Eric Sosman Guest

    [OT] Re: coding trick to reduce number of small objects generated

    Roedy Green wrote:
    > On 4 Aug 2005 20:59:15 -0700, "John Currier" <>
    > wrote or quoted :
    >
    >
    >>Have you guys ever developed in C++? I often long for const in Java,
    >>especially when I have to do this type of cloning to prevent users from
    >>modifying my data.

    >
    >
    > The problem with const in C++ is not everyone understands it and end
    > up bypassing your safety.


    s/const in//
    s/t every//

    s/seriousness/;-)/

    --
     
    Eric Sosman, Aug 5, 2005
    #12
  13. Roedy Green

    Dale King Guest

    Roedy Green wrote:
    > I was reading a book called Java Platform Performance, Strategies and
    > Tactics.
    >
    > It pointed out the bottleneck often turns out to be creating zillions
    > of tiny objects. The author was on the Swing team profiling it to
    > reduce the number of objects generated.


    I'm not sure how true that is anymore with the generational garbage
    collector. If the object is short-lived it is very cheap. Reusing an
    object can actually hurt performance because you have to store the
    reference somewhere that prevents the object from being garbage
    collected for free like short-lived objects in the nursery.

    You should probably see how old that book is.

    --
    Dale King
     
    Dale King, Aug 17, 2005
    #13
  14. Dale King wrote:
    > Roedy Green wrote:
    >
    >> I was reading a book called Java Platform Performance, Strategies and
    >> Tactics.
    >>
    >> It pointed out the bottleneck often turns out to be creating zillions
    >> of tiny objects. The author was on the Swing team profiling it to
    >> reduce the number of objects generated.

    >
    >
    > I'm not sure how true that is anymore with the generational garbage
    > collector. If the object is short-lived it is very cheap. Reusing an
    > object can actually hurt performance because you have to store the
    > reference somewhere that prevents the object from being garbage
    > collected for free like short-lived objects in the nursery.


    The most general advice is don't optimise prematurely and that
    allocation is very cheap. However that's not the full story.

    Allocation still costs. And if you're doing it very fast it can make a
    difference. Microbenchmarks wont note how other threads doing more
    conventional things are getting all their objects shunted out to the
    much smaller survivor space. If there are zillions of long live objects,
    not only is memory use several times higher, but also GC pauses hurt.

    Even in J2SE 5.0 boxing is done using "interned" boxes for small values.
    OTOH, it is extremely easy to make cache overhead comparable to
    allocation, and objects can acquire a nasty medium length lifetime.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Aug 17, 2005
    #14
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marcel Akkerman
    Replies:
    5
    Views:
    912
    Marcel Akkerman
    Feb 22, 2004
  2. Christopher M. Lusardi
    Replies:
    1
    Views:
    362
    Michael Mair
    Nov 16, 2004
  3. SR
    Replies:
    8
    Views:
    396
    Dennis Lee Bieber
    Apr 12, 2006
  4. Christopher M. Lusardi

    How To Reduce Number Files by Putting file1.c and file2.C Together

    Christopher M. Lusardi, Nov 16, 2004, in forum: C Programming
    Replies:
    1
    Views:
    327
    Michael Mair
    Nov 16, 2004
  5. RichardOnRails

    How to reduce duplication in this small JS script

    RichardOnRails, Aug 19, 2011, in forum: Javascript
    Replies:
    21
    Views:
    746
    Dr J R Stockton
    Aug 23, 2011
Loading...

Share This Page