Potential performance concerns with oxy_url() and oxy_xpath() ?

csun
Posts: 4

Potential performance concerns with oxy_url() and oxy_xpath() ?

Thu Dec 21, 2017 1:30 am

Hi,

I notice that if the CSS custom funtions like oxy_url() and oxy_xpath() are used for resolving links in DocBook5, something like:

Code: Select all

link:empty{
content:oxy_xpath(oxy_concat('doc("', oxy_url('${pdu}/', 'a.xml'), '")//@val')) !important;
}


it works, but apparently when it is turned on Oxygen would work noticeably slower. E.g. if I open a Docbook5 XML that contains many links, then turn on the link resolution, Oxygen can usually become unresponsive for even a few minutes.

Is it a known issue that oxy_url() and oxy_xpath() might take a bit long to process? If that’s the case, with Oxygen XML Editor 19, do we have the option of creating our own CSS custom functions to use in a framework, or do we need to create a whole new plugin to make link resolution faster?

Any suggestions are much appreciated.
Radu
Posts: 5257

Re: Potential performance concerns with oxy_url() and oxy_xpath() ?

Thu Dec 21, 2017 12:51 pm

Hi,

Indeed you should avoid using oxy_xpath or at least change the value of the "evaluate" parameter:

https://www.oxygenxml.com/doc/versions/19.1/ug-editor/topics/dg-xpath-function.html

to avoid evaluating the XPath very often like:

Code: Select all

content:oxy_xpath(oxy_concat('doc("', oxy_url('${pdu}/', 'a.xml'), '")//@val'), evaluate, static) !important;


To avoid oxy_xpath completely we have a CSS extension function called oxy_link-text():

https://www.oxygenxml.com/doc/versions/19.1/ug-editor/topics/dg-oxy-link-text.html

this function will call a Java-based API extension of an interface in our Author SDK, you can search for "LinkTextResolver" here:

https://www.oxygenxml.com/doc/versions/19.1/ug-editor/topics/dg-extensions-bundle.html

Our Author SDK which can be used to compile Java extensions can be found here:

https://www.oxygenxml.com/oxygen_sdk.html

Regards,
Radu
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com
csun
Posts: 4

Re: Potential performance concerns with oxy_url() and oxy_xpath() ?

Fri Jan 26, 2018 10:43 pm

Hi Radu,
Thanks for your help! Sorry I didn't reply sooner.

Yes, it makes perfect sense that avoiding the use of oxy_xpath() and doc() could give us a boost in Oxygen performance. I would like to try using oxy_link-text() for populating the value of CSS "content" property. Could you help with a few more questions?

To avoid the I/O operations with doc(), we may need a way to cache the opened file data in the memory (or elsewhere). Does oxy_link-test() come with the option of caching the data? Or, could you let me know where I can find the source code for DocbookLinkTextResolver - hopefully I can build a customized function by calling DocbookLinkTextResolver, and perform the caching with this Java extension?

Meanwhile, it seems that oxy_link-text() cannot be used on the CSS "link" property. Is there a function that is analogous to oxy_link-text(), but can be used in the following case, for replacing the usage of oxy_xpath() and doc() ?

Code: Select all

*[xlink|href]:before{
    link: oxy_url('${pdu}', oxy_xpath(oxy_concat('doc("', oxy_url('${targets}/', 'b.xml'), '")//@Href'), evaluate, static)) !important;
}


Thanks!
Charles
alex_jitianu
Posts: 612

Re: Potential performance concerns with oxy_url() and oxy_xpath() ?

Tue Jan 30, 2018 5:05 pm

Hi,

My colleague Radu asked me to help you with these extensions.

1. The first step is to define a custom anchor. On the link property you should specify an URL with an anchor that contains everything needed to compute, later on, the target:

Code: Select all

.../b.xml#attrName=val

You will need a custom Link Target Element Finder that will know how to use this anchor and identify the target element.

2. Since you are using a custom anchor, you will also need a customized version of the DocbookLinkTextResolver that, again, will know how to interpret the special anchor

To crete these extensions I suggest:
1. You should download the Oxygen SDK. Afterwards, focus on the submodule called oxygen-sample-framework. After executing a mvn generate-resources you will notice a samples directory which will contain the DocbookLinkTextResolver code.
2. Also add the [OXYGEN_INSTALL_DIR]\frameworks\docbook\docbook.jar to the class path of the project.
3. Create a class that extends ro.sync.ecss.extensions.docbook.DocBook5ExtensionsBundle and overwrites the methods:
3.1 ro.sync.ecss.extensions.api.ExtensionsBundle#createLinkTextResolver() and returns the extension of DocbookLinkTextResolver that handles the special anchor.
3.2 and ro.sync.ecss.extensions.api.ExtensionsBundle#createElementLocatorProvider() and returns an extension of ro.sync.ecss.extensions.commons.DefaultElementLocatorProvider that handles the special anchor

If you take a look at the DocbookLinkTextResolver code you will notice that it actually keeps a cache. Please let me know how it goes.


Best regards,
Alex
csun
Posts: 4

Re: Potential performance concerns with oxy_url() and oxy_xpath() ?

Thu Feb 01, 2018 1:39 am

Hi Alex and Radu,

Excellent, the information is really helpful. Thanks again.

Do I understand correctly that even though DocbookLinkTextResolver keeps a cache, when loading the DocBook XML that contains links, the performance would be identical whether we use DocbookLinkTextResolver or doc() and oxy_xpath() ? My guess is that we would always need to parse the targetset (i.e. ${targets}), and the amount of I/O operations are probably the same at this stage, even if we use DocbookLinkTextResolver .

Is there a way to parse the targetset where it doesn't negatively affect Oxygen's performance? For example, I notice that if we insert a link using the OLink dialog box and load the targetset with the Targetset URL drop-down menu, Oxygen is able to respond rather quickly. In this operation, is it parsing the targetset in a manner that is different from what is done during link resolution?

Thanks,
Charles
alex_jitianu
Posts: 612

Re: Potential performance concerns with oxy_url() and oxy_xpath() ?

Thu Feb 01, 2018 4:00 pm

Hi Charles,

My guess is that we would always need to parse the targetset (i.e. ${targets}), and the amount of I/O operations are probably the same at this stage, even if we use DocbookLinkTextResolver.


The current cache maps a node to the resolved linked text. If you have a document that contains many link nodes (like you mentioned in the first post) to the same ${targets}, Oxygen will still parse the ${targets} document once for every link. Afterwards, the cache will kick in and there will be no performance penalties. In your customization of an DocbookLinkTextResolver you can keep an additional cache, make sure you only parse ${targets} once and keep it somehow in memory (Maybe a DOM model)

Best regards,
Alex
csun
Posts: 4

Re: Potential performance concerns with oxy_url() and oxy_xpath() ?

Fri Feb 02, 2018 7:08 pm

Thanks Alex!

If you have a document that contains many link nodes (like you mentioned in the first post) to the same ${targets}, Oxygen will still parse the ${targets} document once for every link.

In your customization of an DocbookLinkTextResolver you can keep an additional cache, make sure you only parse ${targets} once and keep it somehow in memory (Maybe a DOM model)


Before going ahead with customizing the DocbookLinkTextResolver, may I ask - will Syncro Soft plan to develop a similar enhancement? It seems that the performance issue with link resolution could be encountered by most DocBook writers. Thanks.
alex_jitianu
Posts: 612

Re: Potential performance concerns with oxy_url() and oxy_xpath() ?

Mon Feb 12, 2018 12:43 pm

Hi Charles,

Currently, Oxygen handles just internal references (references to other elements that are in the scope of the current document, ID-based) so the caching inside DocbookLinkTextResolver doesn't take have to take care of olink references. It is something that we should handle as well, so I will add an issue for that, but it is not a trivial change. It will definitely not be available in version 20 because there is little time left until its release.

If you have some sample files, it would be great if you can send them to our email address (support@oxygenxml.com). This way, when we start working on the feature, we can make sure it handles your case as well. Is it an use case similar with the one in the Inserting an olink in DocBook Documents or is it a bit different? From your examples above, it is not entirely clear if you are using link elements or not...

Best regards,
Alex

Return to “DocBook”

Who is online

Users browsing this forum: No registered users and 1 guest