http://gwt-code-reviews.appspot.com/291801/diff/1/6 File bikeshed/src/com/google/gwt/collections/MutableArray.java (right):
http://gwt-code-reviews.appspot.com/291801/diff/1/6#newcode49 bikeshed/src/com/google/gwt/collections/MutableArray.java:49: * Creates and immutable array based on this one and resets the contents of On 2010/03/30 16:24:31, Dan Rice wrote:
and -> an
Done. http://gwt-code-reviews.appspot.com/291801/diff/1/6#newcode97 bikeshed/src/com/google/gwt/collections/MutableArray.java:97: E[] newElems = (E[]) new Object[oldLen + 1]; Yes, it is inefficient. I agreed with Bruce writing a simple JRE implementation rather than an optimal one. Using a backing array larger than the actual content (as in ArrayList) we could improve to sub-linear amortized time for add, but we cannot fix inserts or removes (other than removals at the end, which would have constant cost). The trade-off would be wasted space in the form of bigger than necessary backing arrays. I guess we chose the simpler poison. It occurs to me as an option to add a method to grow the array to a chosen length. So something like // N fruits, O(N^2) ma.add("pear"); ... ma.add("apple"); Becomes // N fruits, O(N) ma.grow(N, null); ma.set(0,"pear"); ... ma.set(N-1,"apple"); On 2010/03/30 16:24:31, Dan Rice wrote:
Perhaps this won't matter once this is implemented in JSNI, but it
seems
extremely inefficient to reallocate the backing array for every insert
and
remove.
http://gwt-code-reviews.appspot.com/291801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe from this group, send email to google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
