No errors or warnings, but can't compile about shedskin HOT 14 CLOSED

thanks for reporting!

the x86_64 specific issue is fixed in SVN (some old types are no longer 
supported in
newer versions of GCC):

http://code.google.com/p/shedskin/source/detail?r=751

the other issue is caused by a missing cast (tuple<void *..> should be cast to
tuple<int..> here).. I will look into that. in the meantime, if you'd like to 
compile
the code anyway, you can just change 'void *' with 'int'. 

Thank you :)

Now it's fully working for me. Actually, it's 3.3 time faster, good :)
And with another program that I've wrote, it's 10 time faster :D

Thank you for your work ;)

thanks for the feedback!!

I had a quick look at the problem, and apparently I forgot to add casts for 
yield
statements. so that should be easy to fix.. 

okay, I updated SVN with a fix for this.. thanks again for reporting, and 
please let
me know if you run into anything else.

btw, if you replace this:

for a,b in enumerate(c):

with this:

for a in range(len(c)):
    b = c[a]

you will get a large speedup. this is because with enumerate, you are implicitly
generating lots of tuple objects, which slows down C++ a lot.

also, you might want to use shedskin -bw for a secondary speedup (but note your 
code
for parsing arguments won't raise an IndexError anymore now, but this is easy 
to work
around).

after profiling life_shed.cpp a bit, I decided to optimize list slicing 
(something I
should have done ages ago). this makes the program a bit faster still.. now it's
about 30 times faster here (after replacing the enumerate statements). if you'd 
be
interested in trying, please pull from SVN.

Woow! It's so fast! It's 10 times faster of the last shed_skin version, so 
about 30
times faster of the original version. Thanks :)

I could also have a look at the other program you mentioned, if you like? 

btw, I'm working on a fix so that 'for a,b in enumerate(some_sequence)' will 
become
as fast as manually replacing it.. thanks for reminding me of this useful 
optimization.

Sure ;) This is only a class with a little test, nothing more.
I thinked: it could be possible to use shed for qt programs? c and python use 
the
same methods for qt :)

some tips for better performance:

-use sets for 'in' checks and 'index'. for lists, these imply walking over the 
list
every time (which isn't faster in C++), while for sets, this takes only 
constant time
(one step).

-shedskin -r boosts performance a bit more (shedskin now uses C random numbers
instead of Python compatible ones)

-there is still one problematic line: del self.uids[self.uids.index(uid)]. 
because of
index, but also because 'del' on a list means shifting on average half of the 
list.
you might be able to find a faster solution usings sets or possible a linked 
list, so
half the list doesn't have to be shifted each time.

see attachment for a slightly modified version.

note that you really don't want to compile qt code. because a) interface glue 
won't
get any faster, and b) this would restrict your code too much. a better 
solution is
to compile an extension module (shedskin -e, see the tutorial), and import this 
in
some 'main' program that uses Qt.

Thanks so much, I'll try the extension module approach.

I've changed a bit the test part, when it tries to remove some random items. So 
I can
use only sets. The performance of this python file are shown here:

[frafra@rocketman idee]$ time python idee_shed.py
[...]
real    0m3.777s
user    0m3.676s
sys 0m0.064s
[frafra@rocketman idee]$ ../../shedskin -r idee_shed.py
[...]
[frafra@rocketman idee]$ time ./idee_shed
[...]
real    0m0.209s
user    0m0.162s
sys 0m0.042s

So, about 18 times faster :)
Yes, the test code makes the performances a bit more different for every run, 
but it
doesn't matter :)

I finally sat down and optimized the following in SVN:

.. for var, .. in enumerate(some list/tuple) ..

so the hack with 'for .. in range(len(..))' is not necessary anymore for 
life_shed.

I'm hoping to do something similar for 'zip', before the next release:

.. for .., .. in zip(list/tuple args) ..

both patterns are quite common, so I should have done this a long time ago..

btw, did you try to build an extension module yet?

Actually I'm doing an important exam, please excuse me :) I'll try as soon as I 
can ;)