web design question -- throw away objects

[christopher]

I am creating a back-end for a website, and in the course of
displaying athe various pages several objects are created which
contain info pulled from a database. These objects persist throughout
the session, and if the database is updated I keep the session object
in sync. To extract the data I often provide several Iterators for
the web designer to use in various ways.

My question is about throwing these iterators away vs creating once
and testing every time to see if they exist. Eventually I imagine I
will profile this, but I am curious what approaches y'all take to
little, disposable objects. Do you keep them if there is a reasonable
possibility of reuse? If there is a best practice I would rather
change 15 methods now rather than 150 later.

Cheers!
-- clh

 

[Tom Hawtin]

My question is about throwing these iterators away vs creating once
and testing every time to see if they exist. Eventually I imagine I
will profile this, but I am curious what approaches y'all take to
little, disposable objects. Do you keep them if there is a reasonable
possibility of reuse? If there is a best practice I would rather
change 15 methods now rather than 150 later.

Generally iterators should be thrown away. Indeed, for anything that
isn't a collection, return an Iterable (or subtype) rather than an
Iterator. Look after the design first, before starting on premature
optimisation.

The performance cost of creating a new iterator over reusing one?
Perhaps a dozen cycles.

The cost of keeping an iterator? Very much more difficult. Naive
microbenchmarks will show big improvements. Real code will not. Having
more (small) objects will increase GC times, which microbenchmarks wont
show. Even retrieving a cached object may take significant time if it
has dropped out of the CPU cache. And of course you have more code,
which generally means slower.

Almost certainly network latency will be vastly more important overall
to your application than a few tiny, tiny objects.

Tom Hawtin

 

[christopher]

Thanx!
I am aware of the pitfalls of premature optimization, I just got a
tickle that I am throwing away what could amount to hundreds or
thousands of objects a minute and it became obvious this is a routine
decision other people have dealt with long ago. BTW I am using 1.4 --
no iterables. Frankly, I cannot afford the time to bring every
platform up to current and learn a new API every 6 months. Every 2
years is more my speed, when a new feature will make an important
impact on what I am doing.

"Generally iterators should be thrown away." this is the money line --
thanx again!
-- clh

 

[Tom Hawtin]

I am aware of the pitfalls of premature optimization, I just got a
tickle that I am throwing away what could amount to hundreds or
thousands of objects a minute and it became obvious this is a routine

Thousand of objects a minute? Let's be generous and assume manual
caching, rather than slowing the system down, does actually save a dozen
cycles an allocation. Doing that a thousand times a minute is 12 * 1000
/ 60 = 200 cycles saved a second. On a machine doing, say, 2,000,000,000
cycles a second, that's probably not going to be useful.

decision other people have dealt with long ago. BTW I am using 1.4 --
no iterables. Frankly, I cannot afford the time to bring every
platform up to current and learn a new API every 6 months. Every 2
years is more my speed, when a new feature will make an important
impact on what I am doing.

Or Iterable subtypes. Collection for instance. Unfortunately that
interface may be a somewhat wider than you need.

Tom hawtin

 

[Lew]

Thousand of objects a minute? Let's be generous and assume manual
caching, rather than slowing the system down, does actually save a dozen
cycles an allocation. Doing that a thousand times a minute is 12 * 1000
/ 60 = 200 cycles saved a second. On a machine doing, say, 2,000,000,000
cycles a second, that's probably not going to be useful.

Plus the Java GC is extremely efficient at small, short-lived objects. There
is an overhead of about 12-20 machine cycles for object creation, according to
estimates I've read, and none whatsoever for young generation object
destruction. Java's memory allocation dynamics tend to favor creating small
throwaway objects over hanging on to them.

The overhead of tenured GC for long-lived objects may overwhelm the small
savings in object creation. It very likely will increase programming
difficulty as you try to manage manually what Java can manage quite well
automatically.

This does not apply to objects that maintain external resources, such as
database connections. There the memory management overhead is insignificant
compared to the resource overhead.


Java 5 has been out for about two and a half years, so "6 months" is really
not an issue in this case. If "every 2 years is more [your] speed" then it's
time to take a look.

Java 6 is the current version.

-- Lew

 

[christopher]

hehe I know I am overdue on my 2 year cycle. We have a new server
cluster coming online in a couple months and I am going to mirror that
setup to my development server. My least favorite surprise is finding
out that my 2 year old FreeBSD install is not current enough to run
the Java 1.6 port. Sigh.

Thanks for the info on GC being efficient with small, short lived
objects. I always assumed the intent behind iterators and their kin
was for them to be throw-aways, but assumptions like that can bite
hard.

Cheers!

Thousand of objects a minute? Let's be generous and assume manual
caching, rather than slowing the system down, does actually save a dozen
cycles an allocation. Doing that a thousand times a minute is 12 * 1000
/ 60 = 200 cycles saved a second. On a machine doing, say, 2,000,000,000
cycles a second, that's probably not going to be useful.

Plus the Java GC is extremely efficient at small, short-lived objects. There
is an overhead of about 12-20 machine cycles for object creation, according to
estimates I've read, and none whatsoever for young generation object
destruction. Java's memory allocation dynamics tend to favor creating small
throwaway objects over hanging on to them.

The overhead of tenured GC for long-lived objects may overwhelm the small
savings in object creation. It very likely will increase programming
difficulty as you try to manage manually what Java can manage quite well
automatically.

This does not apply to objects that maintain external resources, such as
database connections. There the memory management overhead is insignificant
compared to the resource overhead.


Java 5 has been out for about two and a half years, so "6 months" is really
not an issue in this case. If "every 2 years is more [your] speed" then it's
time to take a look.

Java 6 is the current version.

-- Lew