i am reworking the implementation a bit to properly support borders and repeaters by delegating to components...will check it in when i have it working...
-igor On Fri, Feb 14, 2014 at 7:26 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > 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 >>
