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

treewalker is substantially faster than xpath #13

Merged
merged 5 commits into from Apr 4, 2019

Conversation

Projects
None yet
3 participants
@retorquere
Copy link

retorquere commented Apr 2, 2019

treewalker is substantially faster than xpath -- I thought it would just be an architectural cleanup, but in my totally subjective hey-this-feels-faster tests, it does seem to make an actual difference, especially on the last test.

Also: address linter reports.

numDOIs++;
if (numDOIs == 2) break;
}
var numDOIs = Object.keys(selectArray).length;

This comment has been minimized.

@adam3smith

adam3smith Apr 2, 2019

Owner

did you understand what was going on here? Why do we break at 2 and not at 1 above?

This comment has been minimized.

@retorquere

retorquere Apr 2, 2019

Author

I thought it was for performance reasons. But come to think of it, then 1 would have sufficed.

This comment has been minimized.

@retorquere

retorquere Apr 2, 2019

Author

The reason I went there at all is that the linter complained.

This comment has been minimized.

@adam3smith

adam3smith Apr 2, 2019

Owner

yup, I know, and it should be possible to do this without the while loop either way (if we want to check for length>1 we can do that) but I want to know what's going on here before changing it.
@zuphilip , do you happen to remember?

@retorquere

This comment has been minimized.

Copy link
Author

retorquere commented Apr 2, 2019

Is the providers array and the stuff with remainingDOIs still relevant now there's only one provider?

@adam3smith

This comment has been minimized.

Copy link
Owner

adam3smith commented Apr 3, 2019

Is the providers array and the stuff with remainingDOIs still relevant now there's only one provider?

You're completely right, I think we can scrap all of that (need to make sure that we're still failing gracefully on DOIs that either aren't DOIs or aren't covered by the search translator)

@retorquere

This comment has been minimized.

Copy link
Author

retorquere commented Apr 3, 2019

You want me to take a stab at that?

@adam3smith

This comment has been minimized.

Copy link
Owner

adam3smith commented Apr 3, 2019

@retorquere

This comment has been minimized.

Copy link
Author

retorquere commented Apr 3, 2019

I couldn't find anything in the existing code that dealt with graceful handling of non-resolvable DOIs. The remaining DOIs were passed to the next provider, but if DOIs went unresolved at the end of that chain, completeDOIs was just called.

@retorquere

This comment has been minimized.

Copy link
Author

retorquere commented Apr 3, 2019

Not that I'd propose changing too much at the same time, but are promises available in browser? So much of this could at a later change be cleaned up with promises.

@adam3smith

This comment has been minimized.

Copy link
Owner

adam3smith commented Apr 3, 2019

if DOIs went unresolved at the end of that chain, completeDOIs was just called

That's graceful enough for given purposes

are promises available in browser

I believe so, yes, but would want @dstillman to confirm. Obviously only four Zotero version 5+

@retorquere

This comment has been minimized.

Copy link
Author

retorquere commented Apr 3, 2019

It's not something I intend to introduce right now, but I can see the outline of how it would look.

Show resolved Hide resolved DOI.js Outdated
Show resolved Hide resolved DOI.js Outdated
@retorquere

This comment has been minimized.

Copy link
Author

retorquere commented Apr 3, 2019

I was a little nervous around removing the IIFE as sometimes async requires it to keep scope, but I've looked at the code and it seems safe. Tests pass.

Show resolved Hide resolved DOI.js Outdated
@adam3smith

This comment has been minimized.

Copy link
Owner

adam3smith commented Apr 4, 2019

This is great, thanks -- and yes, it does feel quite zippy

@adam3smith adam3smith merged commit 5a3ee4b into adam3smith:DOI Apr 4, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.