On Mon, Feb 10, 2014 at 6:01 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote:
> On Mon, Feb 10, 2014 at 6:26 AM, Martin Grigorov <mgrigo...@apache.org> > wrote: > > > > On Mon, Feb 10, 2014 at 9:43 AM, Igor Vaynberg <igor.vaynb...@gmail.com > >wrote: > > > > > i just pushed my new idea into sandbox/component-queueing-2 > > > > > > the way this works now is instead of doing it in onInitialize() and in > > > onConfigure() and all the other places dequeuing now works > progressively. > > > upon a change (container.queue() or component.add()) a dequeue will be > > > tried. > > > > > > it even works well with resolved components like enclosures. for such > > > components the markup of page/panel is traversed in onInitialize() and > all > > > auto components are placed into the queue. later as components are > > > added/queued these components will be placed into the correct place in > the > > > hierarchy. if queue() is used children of these components will be > placed > > > under them in correct hierarchy place. this is a big win for using > queueing > > > over adding. > > > > > > repeaters also work. the repeater items themselves have to be added to > the > > > repeater, but item's children can be queued. this is not a problem > since > > > items are mostly added by framework classes. > > > > > > Borders do not yet work mainly because i havent tried to make them > work. > > > the tricky part there is to keep the border and BorderBody queues > separate. > > > > > > > I've added some code to support it but it needs more work. > > See my response to the commit notification email of my changes. > Basic usage of Border is now supported. I have added a test with nested Borders and it fails. Please check org.apache.wicket.queueing.ComponentQueueingTest#dequeueWithNestedBorders > > > > Also we have BorderBehavior and BorderPanel. > > I think (almost) no one uses those but they exist. > > imho we can nuke these two things from 7. they dont look very useful. > probably added just because we could. > > > > InlineEnclosures do not yet work because the code for figuring out the > > > value of the child attribute is really convoluted for the simple thing > its > > > supposed to do and i didnt bother parsing it. Should be very similar > to how > > > EnclosureHandler works. > > > > > > > Done. > > thanks. > > > > the performance is good. there is ComponentQueueingPerformanceTest > with a > > > disabled test. give it a go and let me know the results. on my box > queuing > > > had under 10% overhead, which is acceptable. I also have some ideas on > how > > > to optimize that further by trading cpu for a bit more memory, but not > sure > > > > > > > In my branch on this topic I used HashMap instead of array. The lookup is > > faster. Not sure how much memory overhead there is. > > yeah. havent had time to profile it yet. there are some memory > efficient hashmaps floating around, maybe we can adapt one of them. > I've added ComponentQueue2 based on HashMap with the same initial capacity (8) and loadFactor 1. wicket-util has MicroMap for 1entry and MiniMap for fixed size entries but it doesn't use hash function so it iterates over the entries as we do over the array in ComponentQueue(1). With ComponentQueue2 the map will start with capacity 8 and will double when the ninth is to be added, as in ComponentQueue. But it won't shrink until it becomes with size 0. org.apache.wicket.queueing.ComponentQueueingPerformanceTest gives almost the same results for both impls here: add duration: ~2500 queue duration: ~2400 memory wise Intellij IDEA reports: - with ComponentQueue: max memory 88Mb - with ComponentQueue2: max memory 154Mb so ComponentQueue is a winner here. I've added ComponentQueue2 just in case someone wants to try to optimize it > > -igor > > > > if its needed since the overhead is low and because its only present > when > > > queuing is used. also the measurements are not too accurate because > most of > > > the time is spent initializing and tearing down a WicketTester > instance. > > > > > > memory overhead is also low, two slots (one of which can/should be > > > converted to a flag) are added to MarkupContainer. > > > > > > see ComponentQueuing test for some examples. i would appreciate some > help > > > getting Border and InlineEnclosure working if someone has time. > > > > > > look over this and lets discuss if/when we should merge it into master. > > > > > > -igor >
