I am creating a back-end for a website, and in the course ofdisplaying athe various pages several objects are created whichcontain info pulled from a database.  These objects persist throughoutthe session, and if the database is updated I keep the session objectin sync.  To extract the data I often provide several Iterators forthe web designer to use in various ways.My question is about throwing these iterators away vs creating onceand testing every time to see if they exist. Eventually I imagine Iwill profile this, but I am curious what approaches y'all take tolittle, disposable objects.  Do you keep them if there is a reasonablepossibility of reuse?  If there is a best practice I would ratherchange 15 methods now rather than 150 later.Cheers!-- clh

christopher@dailycrossword.com wrote:> > 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

Thanx!I am aware of the pitfalls of premature optimization, I just got atickle that I am throwing away what could amount to hundreds orthousands of objects a minute and it became obvious this is a routinedecision other people have dealt with long ago.  BTW I am using 1.4 --no iterables.  Frankly, I cannot afford the time to bring everyplatform up to current and learn a new API every 6 months.  Every 2years is more my speed, when a new feature will make an importantimpact on what I am doing."Generally iterators should be thrown away." this is the money line --thanx again!-- clhOn Mar 12, 1:13 am, Tom Hawtin <use...@tackline.plus.com> wrote:> christop...@dailycrossword.com wrote:>> > 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@dailycrossword.com wrote:> 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 routineThousand 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

christopher@dailycrossword.com wrote:>> 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 routineTom Hawtin wrote:> 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.christopher@dailycrossword.com wrote:>> 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, 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

hehe I know I am overdue on my 2 year cycle.  We have a new servercluster coming online in a couple months and I am going to mirror thatsetup to my development server.  My least favorite surprise is findingout that my 2 year old FreeBSD install is not current enough to runthe Java 1.6 port.  Sigh.Thanks for the info on GC being efficient with small, short livedobjects.  I always assumed the intent behind iterators and their kinwas for them to be throw-aways, but assumptions like that can bitehard.Cheers!On Mar 12, 4:14 pm, Lew <l...@nospam.lewscanon.com> wrote:> christop...@dailycrossword.com wrote:> >> 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> Tom Hawtin wrote:> > 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.>> christop...@dailycrossword.com wrote:> >> 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,>> 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