We are developing a extension of the new profiler (in fact, it is
already here, we are just testing) to cache the generated portletset in
the session, to avoid recomputing the portletset for each request.

This has a heavy impact on performance, as we skip lots of getPortlet()
calls and lots of memory allocations when the psml descriptions are wide
and deep (as it is our case).

I wanted to comment that, to develop this simple extension, I had to
create two classes:

- a new Profile class (inheriting from BaseProfile)
- a new Service (there is no factory to plug new classes there).

I think that the implementation should be in a way that one does not
need to modify the service, but only the Profile class, to extend it.


Also, I wanted to ask if we are switching profiles soon. I have noticed
very little activity in this area recently.


Of course, I will commit the changes as an alternative profile if nobody
oposes. The changes could even be integrated in the default profile,
maybe as a configurable feature.


Also, I wanted to note that the default configuration for the new
Profiler does not work. The anon.dir cannot be empty with the current
implementation, because of "/" trimming and other issues.


The only problem of using cached PortletSets (and Controls and
Controllers) is that, as the Control/lers store state information (which
they should not), the default session gets recovered in whatever state
WRT cards selected that was left by the previous request. This will stop
happening when we clean this part of the API and we recover state from
the Request only.


Comments?


--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?:          [EMAIL PROTECTED]

Reply via email to