[Zope-CMF] Re: Plone Speed

alan runyan alan runyan" <runyaga@runyaga.com
Tue, 14 May 2002 12:27:03 -0500


> > 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.

what do you mean 'used for categorisation' ?
we have broken our 'skin path elements' into sensible structures.  Limi
reminded me this is one of the reasons
we started plone.  generic vs control vs zpt_generic is very hard to
remember where your presentation content goes.

do you mean, using 'skins path elements' == 'categorization'?

> 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.

I understand that.  It would be nice to put CMF into some mode where you
could see all the lookups and give you some optimization hints on what
skinpath elements to have first, etc.

> Now, that includes METAL macro lookups and REQUEST lookups.

yikes. I did not realize REQUEST lookups did this (we took out loads of
REQUEST lookups from plone).  We have also taken out lots of metal macro
lookups.  these things are looked up *each and everytime* ? I thought If a
pagetemplate used a macro, that template was compiled and would  use its
compiled
version instead of looking up the macro and including it.  I can understand
this happening for the standard_htm_header/footer in Plone as that is a
macro hack; then again I dont use DTML (I included it for backwards
compatibility)

> 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.

I can get rid of most of the remaing REQUEST lookups.  I would expect
REQUEST to be in its own namespace before the Portal object.  but I guess
this makes sense come to think about it.

> Ideas for optimisation:

I appreciate the ideas!

> 1. stop using skin layers for categorisation, it's not what they were
designed for ;-)

I just dont understand what you mean by this.  Please be patient, I'm slow.

> 2. reimplement the skins tool so it is designed to have layers for
categorisation ;-)

as I dont understand what categorisation means.. I'm lost at this as well ;(

I just dont see *how* we are abusing the skins tool for doing things we are
not meant to.  we have 'seperated' out skinpath elements into logical units:
plone_templates, plone_scripts, plone_forms, plone_styles.  this seems
intuitive and promoted by the skins tool.  not something that sh/would be
looked down upon.

~runyaga