[Zope-CMF] Re: Plone Speed

alan runyan alan runyan" <runyaga@runyaga.com
Tue, 14 May 2002 13:01:36 -0500


I can understand if request.get('something') would traverse the entire
skinspath?

or.. lets say this in DTML.

<dtml-call "REQUEST.set('something', 'some value')">

later on you say <dtml-var something>, that this has to go through all of
the skin paths and search before it reaches the REQUEST
object?  if thats the case. then specifying the request namespace, which is
done commonly in ZPT as tal:replace="request/something|nothing"
would not traverse the entire skinpath.  it would go directly to request
namespace and look for 'something'.  it would not traverse skinpaths.

??? I could see this maybe being a problem in DTML.  but in ZPT?  I think I
am mising something.

~runyaga


----- Original Message -----
From: "Chris Withers" <chrisw@nipltd.com>
To: "alan runyan" <runyaga@runyaga.com>
Cc: <zope-cmf@zope.org>
Sent: Tuesday, May 14, 2002 11:42 AM
Subject: Plone Speed


> alan runyan wrote:
> >
> > NOTE: I believe the latest Plone has had sigificant speed improvements.
>
> Well, having chatted with AndyD, I think I can give you some clues. From
what I
> understand, you have a lot of skin layers that are used for categorisation
and you find
> METAL slow.
>
> Here's an idea:
>
> The skins tool is not being your friend. For each name you look up in a
CMF site, it goes
> through each layer until you find it, in the order defined in the skins
tool properties,
> as the you hit the portal object in the acquisition chain.
>
> Now, that includes METAL macro lookups and REQUEST lookups.
>
> REQUEST is particularly bad, since it is behind the portal object in the
acquisition
> chain, meaning ALL skin layers will be searched every time it is looked
up. To make
> matters worse, REQUEST is looked up for every page template and metal
macro usage.
>
> Ideas for optimisation:
>
> 1. stop using skin layers for categorisation, it's not what they were
designed for ;-)
>
> 2. reimplement the skins tool so it is designed to have layers for
categorisation ;-)
>
> Maybe Shane can step in here since he may have done some optimisation in
this area
> already?
>
> cheers,
>
> Chris
>