Speed problem in openchemlib-js

[lpatiny]

In javascript the 'long' type does not exists and need to be transpile in a large function. This seems to be the problem in openchemlib-js and explains the difference in speed between java and javascript.

https://github.com/Actelion/openchemlib/blob/master/src/main/java/com/actelion/research/chem/CanonizerBaseValue.java#L49

Would it be possible to create a method that use int instead of long in the method ?

[thsa]

Dear Luc, I hope you had a relaxing time during recent days. Your mail reminded me that we were supposed to meet virtually in the last year. Are you available via Teams or Skype or some other means? I suggest, we meet in the next days to just get a small mutual update... Best wishes, Thomas PS: I believe, one could set a static bit in the CanonizerBaseValue class, that would cause it then to use int instead of long. A JS-program then would have to set this bit just once at its initialization.

…

________________________________ Von: Luc Patiny <notifications@github.com> Gesendet: Montag, 4. Januar 2021 15:58 An: Actelion/openchemlib <openchemlib@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Betreff: [Actelion/openchemlib] Speed problem in openchemlib-js (#63) In javascript the 'long' type does not exists and need to be transpile in a large function. This seems to be the problem in openchemlib-js and explains the difference in speed between java and javascript. https://github.com/Actelion/openchemlib/blob/master/src/main/java/com/actelion/research/chem/CanonizerBaseValue.java#L49<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FActelion%2Fopenchemlib%2Fblob%2Fmaster%2Fsrc%2Fmain%2Fjava%2Fcom%2Factelion%2Fresearch%2Fchem%2FCanonizerBaseValue.java%23L49&data=04%7C01%7Cthomas.sander%40idorsia.com%7Cfbf5578c6dd649abf5dd08d8b0c136b2%7Cbb9214bf0cb941fdbd55d0c1c3eda110%7C0%7C0%7C637453691185301877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Jogn1qQFHfHmr1m6ExBw3v6gRvn5AETnioP75JSKC9A%3D&reserved=0> Would it be possible to create a method that use int instead of long in the method ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FActelion%2Fopenchemlib%2Fissues%2F63&data=04%7C01%7Cthomas.sander%40idorsia.com%7Cfbf5578c6dd649abf5dd08d8b0c136b2%7Cbb9214bf0cb941fdbd55d0c1c3eda110%7C0%7C0%7C637453691185311836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9SDTfWsxVpe07ECj%2BMUUNcGKyYGUs084C8B9UgIRxho%3D&reserved=0>, or unsubscribe<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACNFEBRNSPMW5BYGW2OZDELSYHJRXANCNFSM4VTECXBQ&data=04%7C01%7Cthomas.sander%40idorsia.com%7Cfbf5578c6dd649abf5dd08d8b0c136b2%7Cbb9214bf0cb941fdbd55d0c1c3eda110%7C0%7C0%7C637453691185311836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EqIbhH1HfqQC2wzou5f7kboO%2BlTzi1ZqjFdCnTpatzw%3D&reserved=0>. The information of this email and in any file transmitted with it is strictly confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any copying, distribution or any other use of this email is prohibited and may be unlawful. In such case, you should please notify the sender immediately and destroy this email. The content of this email is not legally binding unless confirmed by letter. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of the sender's company.

[lpatiny]

@thsa I sent you a private message by email and wonder if you received it.

[BobHanson]

FYI - OpenChemLib./Java is now integrated into Jmol/SwingJS. There is no long-value issue there, as SwingJS handles long in a relatively fast, compact way. Luc, how are your processing long in JavaScript? Maybe we can run some comparisons.

[lpatiny]

We are using GWT for transpilation and a long is converted to a javascript class. We are loosing a speed factor of 2.5x as compared with int implementation for substructure search for example. A WASM implementation of openchemlib that supports long would be nice to have and could be the direction to go.

[BobHanson]

FYI today I removed in OCL-SwingJS "nolong" branch (soon to be merged with the master) the most serious of the cases where long is used. Primarily:

Molecule -- all of the atom flags are now int instead of long
Canonizer -- all dependence upon long removed; in[] are used to build the bitsets that are used for ranking

Pretty sure I got this right. It is coding and decoding IDcodes correctly in SmilesParser.main(). I spent quite some time double checking and triple checking all the numerous changes throughout the code. Still, it needs thorough testing that I can't do myself. I'm sure there are lots of query features that were not part of that set, and though I checked and checked, it is conceivable that there are places where a low-byte flag might end up in the high-byte mAtomQueryFeatureH int. All I know is that everything I have tried is working -- lots of canonization -- and all the inchi-related business is working perfectly, and the results of that SmilesParser test set along with ExtendedMoleculeFunctions.analyzeMolecule() reports are identical with my openchemlib checkout.

Performance for OCL-SwingJS JavaScript improved by about 30-50% for a wide range of conversions involving inchi-web-SwingJS wasm (inchi 1.07.2). The relatively small change is probably because SwingJS already handles long operations quite efficiently -- mostly just as standard operations -- but there is still an improvement in removing them altogether. @lpatiny I am pretty sure this would be much faster than whatever GWT is doing. I'd certainly be interested in finding out.

Performance of Java doesn't seem to have been significantly affected one way or the other, but someone else should do a more thorough performance test. On the OCL-SwingJS site, this is tagged as _OCL-SwingJS_nolong.pass.3 3477f1d. I hope it is not significantly slower; might be faster.

JavaScript is performing about as fast as Java, and much faster than Java if frames are involved.

BTW I noticed that my pushes are showing up cross-project on the openchemlib project. I did not intend that, and they should probably just be ignored. Please don't take that as an indication that I expect any action at all on your end. The code is (manually) synchronized with recent work in openchemlib through yesterday, but still there are a few other changes -- primarily wrt asynchronous dialogs -- that you would want to think about before implementing. Really there should be no problem; it makes no change in Java; it just makes the modal Swing dialogs work for both Java and JavaScript.

A busy weekend for me.
Enjoy.

[BobHanson]

ps -- I tried to stay away from the heavy-duty cheminformatics methods in calc and other places, or jfx, but there was one bit I did adjust. There is never any need to express rrggbbaa colors as longs; I switched those to ints (and of course did not test it). It also uncovered what I think is a bug in the ...share.gui.editor.geom.IColor interface (not sure that is actually used) to whit:

public interface IColor
{
public static final long BLACK = 0x000000FFl;
public static final long WHITE = 0xFFFFFFFFl;
public static final long RED = 0xFF00000FFl;

count those digits. Can't do that in an int.

;)

[BobHanson]

no comments here; just reiterating that long is out from ExtendedMolecule for parameters options in the SwingJS fork. Seems to be working perfectly.