[Erp5-dev] programmable acquisition and performance

[bartek]

Hello

I find programmable acquisition very convenient, and I started using it
rather extensively for a project I'm working on (e.g. my "group" base
category has 5 "acquisition_base_categories"). I noticed a considerable
decrease in performance, but I'm not sure whether this is the reason -
is programmable acquisition so heavy? And if so, then why, and can it be
optimized somehow?

Bartek

[Pelletier Vincent]

Post by bartek
Hello

Hi Bartek

Post by bartek
I noticed a considerable
decrease in performance, but I'm not sure whether this is the reason -
is programmable acquisition so heavy? And if so, then why, and can it be
optimized somehow?

As noted in the [1] wiki page ("Is there any side effect by the patch?"
section), _aq_dynamic is called every time __getattr__ returns None.
So every time a skin lookup is done (form, page template, script, etc) the
custom acquisition method will be fired, for example.
I think the first optimisation to do is to have a quick check at _aq_dynamic
begining to detect cases where it will return None, and do so immediately.

[1] http://www.erp5.org/WhyAqDynamicIsRequired

[Jean-Paul Smets]

Hi,

I think bartek is discussing another issue: the acquisition of values
through categories.

- convenient: yes
- heavy: potentially, yes
- optimisable: not sure

This is why we use it when it is the clean way to do and we try not to
use it when it is not necessary.

There are already optimisations (with read only transaction caches).

I am not sure if it is possible to optimise it so much because part of
the performance cost is related to the access time to many ZODB objects
rather than a few. The first kind of optimisation to do is to try to
call the accessor once in a transaction rather than 10 times.

Regards,

JPS.

Post by Pelletier Vincent

Post by bartek
Hello

Hi Bartek

Post by bartek
I noticed a considerable
decrease in performance, but I'm not sure whether this is the reason -
is programmable acquisition so heavy? And if so, then why, and can it be
optimized somehow?

As noted in the [1] wiki page ("Is there any side effect by the patch?"
section), _aq_dynamic is called every time __getattr__ returns None.
So every time a skin lookup is done (form, page template, script, etc) the
custom acquisition method will be fired, for example.
I think the first optimisation to do is to have a quick check at _aq_dynamic
begining to detect cases where it will return None, and do so immediately.
[1] http://www.erp5.org/WhyAqDynamicIsRequired