Hi Martin 2012/12/20 Martin Marinschek <[email protected]>: > Hi Leo. > > what are you trying to gain from this? > > Here the criticism from the link you provided: > > Criticism > > Some publications do not recommend using object pooling with certain > languages, such as Java, especially for objects that only use memory and > hold no external resources.[2] Opponents usually say that object allocation > is relatively fast in modern languages with garbage collectors; while the > operator new needs only ten instructions, the classic new - delete pair > found in pooling designs requires hundreds of them as it does more complex > work. Also, most garbage collectors scan "live" object references, and not > the memory that these objects use for their content. This means that any > number of "dead" objects without references can be discarded with little > cost. In contrast, keeping a large number of "live" but unused objects > increases the duration of garbage collection.[1] In some cases, programs > that use garbage collection instead of directly managing memory may run > faster. > > > what do you say about this?
To avoid the effect over garbage collection, the view pool proposed uses soft or weak references to hold UIViewRoot instances and to avoid lower performance by concurrency effect, the pool does not have any synchronized block it uses a ConcurrentLinkedQueue with a upper limit set by an atomic var (just one synch block and the performance will be lower than do not using anything at all). The effect of use soft/weak references is that the region of memory holding the instance can be always reclaimed by the garbage collector, avoiding memory fragmentation. >From memory perspective, the cache improves memory usage because less object needs to be created per request, so the pressure over gc becomes many times lower, and at the end we have less calls for gc and a better performance at the cost of have a higher memory footprint. In MyFaces case, we have done the best effort to keep component tree "as light as possible", which means create the less amount of objects per component. This makes view creation very fast, but anyway, the amount of objects that still needs to be created per view are enough to consider object pooling technique. The tests done under high concurrency (200 threads) shows an improvement of about 8% rendering full pages. The reason is the build view time for our facelets algorithm is already very fast, and render the view is the operation that takes more time. But in ajax cases the improvement is even more, because in that case, usually the portion that needs to be rendered from the view is small, and the build view time becomes more significant. The difference will be more significant if the view is larger. Is the technique good enough to be included in MyFaces? In my opinion yes, because given the considerations done there is a gain even in the most simple cases. But not everything is perfect. The technique suppose PostAddToViewEvent will not be called in each request, if you use c:set, ui:param or something that makes ValueExpressions depends on VariableResolver and in that way make necessary to create them at each request, the view becomes non poolable, and it also requires some small modifications over components to allow reset the component. In any case, the proposed patch will help to clear the misunderstandings about stateful vs stateless web frameworks and the implications in performance. best regards, Leonardo > > best regards, > > Martin > > > On Mon, Dec 17, 2012 at 5:23 PM, Leonardo Uribe <[email protected]> wrote: >> >> recover > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces
