Re: psyco

Pierre-Frédéric Caillaud <[email protected]>
Newsgroups gmane.comp.web.skunkweb
Organization La Boutique Numérique
Message-ID <opsauxfjrycq72hf@musicbox>
> I'd have to call this a compelling benchmark!  Is this Python 2.3.4?

	Yes.
	
> I am concerned about how this would affect includes.  One possibility
> that occurs to me is to wrap components in a function if and only if
> they have a compargs tag, which would directly yield the function
> signature.

	You could also use **kwargs to feed a dict as arguments to a function ?
	Anyway, compargs is very useful, not using it is a source of bugs...

> I'm not thrilled about the idea of the code being
> generated for an STML file depending on whether it is called as an
> include or a component; at least, by relying on <:compargs:>
> declarations, the generated wrapper function would be somehow
> explicit.

	Isn't it specified by the file extension ?

> It should also be pointed out that it is fairly absurd to do any
> heavy-lifting in STML at all, although I have seen it done.  That is
> what Python components are for, and you can write functions in them to
> your heart's content.

	Well, STML is only for presentation, and it should stay that way.
However, in my application, most of the processing time is in STML for
formatting the output, and even if the application logic work is quite
complex, it's still faster...

>   from a import *
> is not legal outside of module scope:

	Hum, then your source compiler could turn a component into a module with
the following contents :

	import stuff
	from foo import *

	def comp_function( params ):
		... actual compiled code

	Putting the imports outside the function def would solve this problem.

>> 	***************************************
>> 	* About <:val:> tag

> This could definitely be done and benchmarked against the current
> code.    Patches will be considered :).

	It seems like an ideal candidate for a quick hack ;)
	val could even be a method of OUTPUT because it's used so often.

>> 	You could also save a few lookups by putting __h.OUTPUT.write in a
>> variable.
>
> Well, that variable would have to be stashed somewhere, too.  The __h
> mechanism is a bit expensive, admittedly.  In stoat, btw, there are no
> games with stdout (can't be, as stoat is supposed to be threadsafe), and
> the output stream lives directly in the component namespace for  
> components
> that use it.
>


> This is somewhat configurable at the moment.  Look at the noTagDebug
> and dontCacheSource options.

	OK !

>
>> 	Then, the compiled template would only contain lines like :
>> __d.CURRENT_POSITION  = (1, 10, 20)
>> 	the tuple being : file id, tag id, line id (or something like that).
>> 	One tuple = one assignment (instead of two)
>>
>> 	The tag, file, etc. would be retrieved from these ID's when an error
>> occurs.
> Hmmm -- is tuple creation actually faster than assignment?

	I just checked, and ...actually, yes.
	In your example, it's about the same, but if you make assignments like :
	__d.CURRENT_POSITION then you have an additional attribute lookup per
assignment, which makes it a lot longer.

	Results and example code below :

globals (,,):  0.928138017654
globals :  1.73310303688
locals (,,) :  0.737425088882
locals :  1.38989400864
psyco :
locals (,,) :  0.316897153854
locals :  1.01649093628


import time
import psyco

test_len = 1000000

class testclass( object ):
	pass

# test globals
t = time.time()
base = testclass()
for i in xrange(test_len):
	base.a = (1,2,3)
print 'globals (,,): ', time.time() - t

# test globals
t = time.time()
base = testclass()
for i in xrange(test_len):
	base.a = 1
	base.b = 2
	base.c = 3
print 'globals : ', time.time() - t
del base

# test locals
def test():
	t = time.time()
	base = testclass()
	for i in xrange(test_len):
		base.a = (1,2,3)
	print 'locals (,,) : ', time.time() - t
	
	t = time.time()
	base = testclass()
	for i in xrange(test_len):
		base.a = 1
		base.b = 2
		base.c = 3
	print 'locals : ', time.time() - t

test()

# test psyco
psyco.full()
print 'psyco : '
test()

	Have fun !


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.