coding trick to reduce number of small objects generated

[Roedy Green]

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

 

[Thomas Hawtin]

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

 

[Mike Schilling]

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_.

 

[jan V]

Also see Flyweight design pattern in GoF book....

 

[Filip Larsen]

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,

 

[Roedy Green]

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

 

[John Currier]

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

 

[Thomas Hawtin]

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

 

[Thomas Hawtin]

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.)

 

[Raymond DeCampo]

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

 

[Roedy Green]

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

 

[Eric Sosman]

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/;-)/

 

[Dale King]

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.

 

[Thomas Hawtin]

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