My guess about .select(processor=..) when compared to having a separate
"flat" function, is that the additional layer of indirection (function
invocation) incurs a small penalty that shows-up.
I did a non-web2py-related test earlier, that showed consisant x2.2 penalty
of adding a single-layer of indirection, by re-factoring-out a line into a
single-liner function
Was something like this:
amount = 100
def doWorkDirectly():
List = []
for i in range(amount):
List.appent('a')
def doWork(List): List.append('a')
def doWorkIndirectly():
List = []
for i in range(amount):
doWork(List)
if you bench doWorkDirectly against doWorkIndirecty, you would get a very
solid and sonsistant x2.2 penalty in favor of doWorkDirectly - regardless
of the order-of-magnitude of 'amount' (same gap for 10, 1000 and 100000)...
So this is a c-python implementation detail.
Granted, it would show-up more in very simple processing-payload, as there
the invocation-overhead overshadows the actual computation expense - in
more expensive procedures, there would still be the same penalty, but it
would be less noticeable.
So, passing a one-liner callback (or a lambda, though I havent tried
that...) into ".select(processor=...)", for a computationally-simple
expense such as zipping a list into a dictionary, .may fall into that
category - you may loose more than you gain by it...
As for the parsing logic - that's beyond me, personally...
Shouldn't that move into the web2py-devs group?
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
