[Zope-CMF] Accessing skins objects

[Charlie Clark]

Am 09.02.2009 um 18:53 schrieb Tres Seaver:

> This is talking directly to Zope (no Varnish / Squid in front?)   
> Please
> post the PythonScript, too.

Yep, this is a local wget talking directly to Zope.

The PythonScript is:

request = context.REQUEST
styles = []
styles.append(getattr(context,  
'content_global.css').index_html(request, request.RESPONSE))
styles.append(getattr(context, 'default.css').index_html(request,  
request.RESPONSE))
#... lots more file

return "\n".join(styles)

Now the profile results:
1) View
  4499 function calls (4476 primitive calls) in 0.110 CPU seconds

2) PythonScript
  12830 function calls (12786 primitive calls) in 0.154 CPU seconds

The 3:1 ratio is probably down to the way index_html works for the  
files.

So the PythonScript is more CPU intensive but also delivers faster.  
Going on what you suggested yesterday I suspect the difference is down  
to how the request is written to. I'll see if I can get something  
working with that IFilestreamIterator you suggested.

>>> The FSFile
>>> object *never* stores the bits read from the filesystem, so the more
>>> likely case is that your view is hitting some other bottleneck.
>>
>> oh, what FS things are affected by the debug-mode flag that forces
>> them to be reread?, ie. which objects don't reflect underlying file-
>> system changes?
>
> Other FS objects may have cached information computed from the file
> (e.g., the compiled template bytecode for an FSPageTemplate, or  
> bytecode
> for an FSPythonScript).  But there is nothing which reads FSFile data
> into memory and holds it.  both its '__str__' and its 'index_html'
> reread the file from dist.  However, the object *may* be cached by a
> RAMCache or an AcceleratedHTTPCache, if one is configured.

No, very little caching is active at the moment.

> If Globals.DevelopmentMode is enabled, then the call to  
> '_updateFromFS'
> in both of those methods ('__str__', 'index_html') removes the object
> from the cache on each request.

Yes, I've seen this is how _readFile() works.

>>> BTW, it might be faster to compute the *filenames* in the memo, and
>>> then
>>> return an IFilestreamIterator which chunked the response by reading
>>> the
>>> files one at a time.  Running 'cat /path/to/fsidr/*.js' in an
>>> os.system() call might be faster, too ;)
>>
>>
>> I quite like the iterator idea.
>
>> BTW. Can I admit at this stage that I
>> don't really understand what the memoize method does? 8-)
>
> It caches the result of the method call in the view's instance
> dictionary.  Be *sure* to use it only for views:  using it on a  
> content
> objecct would be disastrous.


I'd read the method and figured that's what it does. But because I'd  
never seen the pattern before I wasn't sure. If we do use it, we only  
use it views. Having it in browser.utils is a handy hint there. I have  
hit problems when combining it with decode - obvious when one thinks  
about it - but as all our objects return data in unicode (most are  
managed through formlib forms with some stuff stored in an RDBMS with  
the driver configured to coerce unicode) decode isn't necessary.

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226