Chronological Thread 

< Chronological >      < Thread >

---

Hi Andrew,

> getPositionInXML needs to traverse the entire DOM to find the position of
the
> desired target variable for each call - it does not cache position
information
> so it re-does the calculation for each call from the start of the
document.

Ok, that's what I then thought from having a look at the code.

> If you just want to take a user to an element when they click on it, it
would be
> better to use the element itself rather than the position to find that
element.

How do you mean "click on it"? Click on what? Right now, I am thinking about
someone opening a CellML file and having that file presented to the user in
a 'simple' text editor. From there, there would be a list of
errors/warnings. The user could then double click on a list item and this
would get him straight to the line/column where the error/warning is. This
is what I would like to have for my 'Raw CellML' view and, right now, it
seems like I can't offer that functionality unless the user is willing to
wait 40+ seconds to open the moderately big model I mentioned in my original
message.

> I'd suggest trying to call it as late as possible so you aren't calling it
for a large
> batch of elements.

When someone opens a CellML model, I want that person to know straightaway
whether the model contains errors/warnings, so not an option.

> Because the DOM is 'live', caching positions in the DOM is difficult (for
> example, it is valid to perform a validation, then insert an element into
the
> DOM, then look up a position in the DOM - and the position is supposed to
> reflect the new location). We could make the DOM cache positions with a
> serial number, and change the global serial number any time any change is
> made to any DOM; however, a better approach might be a new service
> designed to efficiently label positions in a particular unchanging version
of
> the document, so that large batches of positions can be found.

I am not questioning that certain things may be technically difficult to
achieve, but from an end-user's perspective all I care about is for the
CellML API to be fast (in this particular case) and, sadly for me, this is
not the case here.

So, in the end, I feel like I am going to have to 'cripple' OpenCOR so that
it doesn't suffer (too badly) from the current CellML API limitations,
something I have already had to do...

Alan

---

• [cellml-dev] Very slow getPositionInXML function in VACSS, Alan Garny, 01/19/2012
  • [cellml-dev] Very slow getPositionInXML function in VACSS, Andrew Miller, 01/19/2012
    • [cellml-dev] Very slow getPositionInXML function in VACSS, Alan Garny, 01/19/2012
      • [cellml-dev] Very slow getPositionInXML function in VACSS, Andrew Miller, 01/19/2012
        • [cellml-dev] Very slow getPositionInXML function in VACSS, Alan Garny, 01/19/2012
          • [cellml-dev] Very slow getPositionInXML function in VACSS, Jonathan Cooper, 01/19/2012
            • [cellml-dev] Very slow getPositionInXML function in VACSS, Alan Garny, 01/20/2012

---

Archive powered by MHonArc 2.6.18.