Chris, would you like to merge the 'apply' branch back into the 1.3
line? It will need to have all the changes which have occurred within
the 1.3 line ported to it first. The profiling results you presented
at https://mail.gna.org/public/relax-devel/2006-10/msg00133.html
(Message-id: <1161682551.7703.107.camel@mrspell>) is probably because
the python profiler is notoriously inconsistent with its timings! I
get similar inconsistencies when I profiled model-free optimisation on
test data that I'll soon add to the 'test_suite' branch (synthetic
data where S2f = 0.952, S2s = 0.582, and ts = 32 ns).
Would you also know the status of the 'auto_select',
'auto_select_merged', and 'macraild' branches of the repository
(http://svn.gna.org/viewcvs/relax/branches/)? They haven't been
touched for over half a year, do you think it would be ok to delete
them?
Cheers,
Edward
On 10/16/06, Chris MacRaild <c.a.macraild@xxxxxxxxxxx> wrote:
The discussions of relax performance on relax-users
https://mail.gna.org/public/relax-users/2006-10/msg00024.html reminded
me of something I noticed recently and forgot to mention here. There are
several instances in relax where the apply() built-in function is used.
According to the Python Library Reference, apply(func, args, kwds) is
exactly equivalent to the extended call syntax: func(*args, **kwds). For
this reason apply has been deprecated since Python 2.3. In some very
quick and inexhaustive tests, I found replacing apply with func(*args,
**kwds) in relax to work, and indeed to give a significant performance
improvement (perhaps as much as 20%).
So, a couple of questions:
Is there a reason for sticking with the apply syntax that I've missed?
Can we efficiently test the replacement to ensure no subtle breakages?
Edward, at some point you mentioned the idea of high-level testing based
on the extensive back-calculated data you have. How much work would be
involved in getting that going?
Chris
Re: apply