On Tue, Feb 18, 2014 at 3:29 PM, Martin Grigorov <mgrigo...@apache.org>wrote:
> > > > 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 > the memory can be ignored. I've rerun the test several times and IDEA shows very different things - from 65Mb to 365Mb but the needed time is 11-12s, was 9s last Friday the sysout is: add duration: 3285 queue duration: 3203 , was ~2400 last Friday > > >> >> 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 >> >>> >> > >
