Background

This entry is just a follow-up to a project I started last year. Last year I worked on implementing a new math package in JSBML, an open source API for manipulating SBML files. With the assistance of my mentors I replaced the existing monolithic design with a newer, more intuitive type hierarchy that captures all the different kinds of Abstract Syntax Tree nodes (AST nodes). Afterwards we implemented a facade class that incorporates the new design but in a way that does not disrupt the old system. The facade class was useful because it allowed us to incorporate the new changes while still maintaining the existing API. Various applications depend on JSBML and expect the AST nodes to behave in a certain way. Therefore it made sense for us to roll out the changes slowly.

At the moment the facade class looks to be functional but just to finalize the entire project I decided to profile both the old ASTNode class and the new facade class (that incorporates the new class hierarchy). All in all, I’d say the results mirrored my expectations. The old ASTNode class did not factor hugely into the performance of the Simulation Core Library. However, the new class hierarchy will be much easier to maintain, and this bodes well for the library’s future stability.

The results of my investigations are shown below:

Results

Chart showing performance of Simulation Core Library while using the old _ASTNode_ class
Chart showing performance of Simulation Core Library while using the _ASTNode_ facade class

The two charts above show the total time spent simulating all the models in SBML test suite 2.2.0. There was no significant difference in performance between the original ASTNode and the new ASTNode. It took roughly 30 minutes to simulate all the models. Simulation on the ASTNode facade took longer (by 2 minutes) perhaps because:

  • Eclipse was running while the tests were being performed.
  • Profiling started earlier. JVisualVM did not profile the performance of the library starting from the first models, but rather the 10th model (in the case of the original ASTNode) and the 6th model (in the case of the new ASTNode). Why the inconsistency? The profiling had to be done manually. I don’t know of any way I can start profiling right at the start with JVisualVM. What all of this implies is that relative to the original ASTNode class most methods called for the new ASTNode class have greater invocation counts. Of course a greater number of invocation counts leads to a greater amount of time spent because each invocation produces overhead.
  • Manipulating the underlying ASTNode2 objects in the facade produces overhead.

The machine on which these tests were performed, had the following specs:

System specifications of test machine

CSV files providing information on the invocation count and total time spent calling each method are available for download. Click here to download the file for the original ASTNode class and here for the file corresponding to the ASTNode facade.

References

  1. Rodriguez, Nicolas, et al. “JSBML 1.0: providing a smorgasbord of options to encode systems biology models.” Bioinformatics (2015): btv341.
  2. Keller, Roland, et al. “The systems biology simulation core algorithm.” BMC systems biology 7.1 (2013): 55.