Iterators are a special case. You have to trade off the object construction/GC cost versus the algorithmic complexity of traversing the particular list start-to-finish without an Iterator (ie: O(n^2) for LinkedList; O(n) for ArrayList).
From: http://code.google.com/android/toolbox/performance.html#foreach """The enhanced for loop (also sometimes known as "for-each" loop) can be used for collections that implement the Iterable interface. With these objects, an iterator is allocated to make interface calls to hasNext() and next(). With an ArrayList, you're better off walking through it directly, but for other collections the enhanced for loop syntax will be equivalent to explicit iterator usage.""" I'm not suggesting we should design specifically for the embedded case, but that it would be helpful to be aware of it. Dave On Wed, Oct 29, 2008 at 9:39 AM, Ed Merks <[EMAIL PROTECTED]> wrote: > David, > > So iterators are bad? :-P > > Cheers, > Ed > > > David Orme wrote: > > Re: explosions of inner classes > > On Android (and probably other embedded VMs) construction is expensive and > also leads to more GC pauses. Google recommends minimising architectures > that force a lot of short-lived objects. > > Just one more data point for the discussion. > > -Dave Orme > > On Oct 29, 2008 5:30 AM, "Oberhuber, Martin" < > [EMAIL PROTECTED]> wrote: > > Hi Scott, > > to me, Futures and Listeners don't need to be a contradiction. > What's more interesting to me, is how to deal with Progress. > When a Progress Monitor already exists for the client, then > using it makes a lot of sense even if the result is obtained > asynchronously: > > final CBFuture<IFileStore[]> childrenF = myFileStore.list(myProgress); > childrenF.chain(new Callback() { > public void onDone(IStatus result) { > if (result.isOK()) { > handleResult(childrenF.get()); > } > }; > }); > > I'm using class "CBFuture" as an "enhanced Future" that allows > registering Callbacks. Using a Callback style of handling things, > or CBFuture.waitFor() remains up to the client. Note that I'm > using a "chain()" method to indicate that the Framework/Future could > allow chaining multiple callbacks such that one is exeucuted after > the other. Also note how the callback retrieves the result of > computation from the Future, and not from the callback itself. > > The problems that I have seen with callbacks in our products > in the past are listed on > http://wiki.eclipse.org/E4/Pervasive_Themes#Becoming_More_Asynchronous > > * Much boilerplate code - Closures would be nice to avoid explosion > of anonymous inner classes, which could cause bloat > > * Need clarification on what thread and in what context the > callback will be called > > * When debugging, it is very hard to trace back the flow of > operation across multiple callback invocations. It can even > make debuging close to impossible unless some Tracing > functionality for the callbacks is built into the Framework > (we ended up doing this in our commercial product). > > * Exception handling needs to be clarified. Java6 Future only > provides Future#isCanceled(), that's not enough since the > result of an operation might also be an exception. I'm > introducint "Istatus result" above but that's also not > optimal. > > The synchronous variant needs more verbosity writing it than > one would expect, because cancellation and errors (exceptions) > need to be handled, wrapped and potentially re-wrapped with > Futures: > > final CBFuture<IFileStore[]> childrenF = myFileStore.list(myProgress); > try { > handleResult(childrenF.get()); > } catch(CancellationException e) { > throw new OperationCancelledException(e); > } catch(ExecutionExeption e) { > throw new CoreException(new Status(/*.blabla*/)); > } > > although that could perhaps be simplified if we declared some > Eclipse specific implementation of Future which throws the > kinds of Exceptions that we already know (like CoreException > embedding an Istatus) instead of the JRE's ExecutionException > that's really alien to our current code. > > Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project... > > _______________________________________________ eclipse-incubator-e4-dev > mailing list eclipse-incuba... > > ------------------------------ > > _______________________________________________ > eclipse-incubator-e4-dev mailing [EMAIL > PROTECTED]://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev > > > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev > >
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
