CellML Discussion List

Text archives Help


[cellml-discussion] Opinions wanted: Should CCGS performanceimprovements go into the 1.0 CellML API branch?


Chronological Thread 
  • From: david.nickerson at nus.edu.sg (David Nickerson)
  • Subject: [cellml-discussion] Opinions wanted: Should CCGS performanceimprovements go into the 1.0 CellML API branch?
  • Date: Tue, 07 Nov 2006 10:11:42 +0800

So are you saying that every time I choose a model in the list of
available models in pcenv the code gets re-generated? If so, then I
guess that explains the slowness....

Personally I see this lack of performance as a severe usability bug that
will have a major impact on the uptake of PCEnv by potential users. As
such and given you seem to already have a potential solution, I would
like to see the changes you mention in the 0.1 release of PCEnv. If the
0.1 release of PCEnv is going to be using the 1.0 release of the CellML
API then I would say yes to including the CCGS performance improvements
into the 1.0 CellML API branch.

On the other hand, if it is the RDF generation for mozilla which is the
main bottle neck in the time taken to switch between models in pcenv,
then I don't see a need to include the changes in the 1.0 CellML API branch.

David.

Andrew Miller wrote:
> David Nickerson wrote:
>> Initial thoughts on 0.1rc1:
>>
>> Much improved integration performance, but have no time to fully test it
>> ;-)
>>
>> It is painfully and prohibitively slow to load a model or to swap
>> between models. Similarly for cloning a model. This seems true for both
>> simple models with very few variables (i.e. 1952 Hodgkin & Huxley) and
>> more complex models with many variables.
>>
> A big chunk of the problem was due to the time taken for the code
> generation (the remaining issue is the time taken to fetch and translate
> the data into the RDF used at the Mozilla-side to describe the tree
> control contents). For the Zhang SAN model from Alan Garny (which was
> one of the slower models for code generation), callgrind reported that
> code generation took 1,947,794,509 CPU operations to generate the code
> prior to revision 585. With only the revision 585 memoisation patch,
> that is down to 1,376,183,895 ops. With the revision 586 patch (which
> finds source variables for all variables at the beginning, using a
> disjoint sets data-structure, instead of individually finding source
> variables using the CellML API), the time was further reduced to
> 890,363,772 ops.
>
> Revision 585 is a relatively minor, low risk change, which could
> potentially be put onto the 1.0 branch of the CellML API if there was
> sufficient interest in this. However, revision 586 is a much more
> significant change, and it even changes the order of variables outputted
> (order is supposed to be unimportant, but it still means the testsuite
> had to be changed).
>
> If you have any opinions on which patches should be merged into the 0.1
> branch (as opposed to being kept on the trunk branch), please send it to
> the list.
>
> Best regards,
> Andrew
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

--
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: david.nickerson at nus.edu.sg




Archive powered by MHonArc 2.6.18.

Top of page