On Mon, Feb 17, 2014 at 5:48 AM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote:
> i think the implementation is good enough to be merged into master > now. it supports: > I am still not able to fix the tests I will need more time to get acquaint with the new code to be able to maintain it > > * dequeuing algorithm that delegates to components so subclasses can > override (this is how repeaters and borders support it) > * support for all major constructs: panels, borders, repeaters > * support for auto component hierarchy - they are dequeued and queued > up children are placed as the children of auto components - this makes > things like enclosures trivial to implement where as before they were > fairy complex > * performance comparable to adding, still some room for improvement > with clever/efficient data structures maybe, but i dont think its > needed... > I see regression here last time I ran the performance test it needed 9s to run and used 88Mb memory now the time is 11s and the memory is 201Mb > > todo: > > * fragments - should be trivial, possibly as trivial as letting it > implement IQueueRegion > * check markup inheritance works on pages, panels, fragments. > * examples > * update to the guide > > -igor > > > > > > On Fri, Feb 14, 2014 at 8:36 AM, Igor Vaynberg <igor.vaynb...@gmail.com> > wrote: > > 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 > >>> >
