Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > coding trick to reduce number of small objects generated

Reply
Thread Tools

coding trick to reduce number of small objects generated

 
 
Roedy Green
Guest
Posts: n/a
 
      08-03-2005
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/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes
 
Reply With Quote
 
 
 
 
Thomas Hawtin
Guest
Posts: n/a
 
      08-03-2005
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/
 
Reply With Quote
 
 
 
 
Mike Schilling
Guest
Posts: n/a
 
      08-04-2005

"Thomas Hawtin" <(E-Mail Removed)> wrote in message
news:42f1560e$0$24049$(E-Mail Removed)...
> 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_.


 
Reply With Quote
 
jan V
Guest
Posts: n/a
 
      08-04-2005
Also see Flyweight design pattern in GoF book....


 
Reply With Quote
 
Filip Larsen
Guest
Posts: n/a
 
      08-04-2005
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


 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      08-05-2005
On Thu, 04 Aug 2005 03:12:39 GMT, "Mike Schilling"
<(E-Mail Removed)> 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/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes
 
Reply With Quote
 
John Currier
Guest
Posts: n/a
 
      08-05-2005
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

 
Reply With Quote
 
Thomas Hawtin
Guest
Posts: n/a
 
      08-05-2005
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/
 
Reply With Quote
 
Thomas Hawtin
Guest
Posts: n/a
 
      08-05-2005
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/
 
Reply With Quote
 
Raymond DeCampo
Guest
Posts: n/a
 
      08-05-2005
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to reduce duplication in this small JS script RichardOnRails Javascript 21 08-23-2011 10:46 AM
general coding issues - coding style... calmar Python 11 02-21-2006 10:36 AM
How To Reduce Number Files by Putting file1.c and file2.C Together Christopher M. Lusardi C++ 1 11-16-2004 12:38 PM
better to compress the jpeg or reduce resolution or reduce pixel size? Mr.Will Digital Photography 8 10-08-2004 03:16 PM
XSLT reduce or count number of matching output elements Marcel Akkerman XML 5 02-22-2004 02:48 PM



Advertisments