Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Speed problem in openchemlib-js #63

Open
lpatiny opened this issue Jan 4, 2021 · 4 comments
Open

Speed problem in openchemlib-js #63

lpatiny opened this issue Jan 4, 2021 · 4 comments

Comments

@lpatiny
Copy link

lpatiny commented Jan 4, 2021

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
Copy link
Contributor

thsa commented Jan 5, 2021 via email

@lpatiny
Copy link
Author

lpatiny commented Jan 8, 2021

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

@BobHanson
Copy link

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
Copy link
Author

lpatiny commented Jan 16, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants