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

Optimise uses of ndarray #170

Closed
2 of 5 tasks
axelboc opened this issue Jun 10, 2020 · 3 comments · Fixed by #198
Closed
2 of 5 tasks

Optimise uses of ndarray #170

axelboc opened this issue Jun 10, 2020 · 3 comments · Fixed by #198
Assignees

Comments

@axelboc
Copy link
Contributor

axelboc commented Jun 10, 2020

  • Split useMemo in two in VisProvider (one for ndarray creation, one for slicing).
  • Simplify unpack(mappedView).flat() by unpacking a flat array directly.
  • Find domain with cwise.
  • Create data points for line vis with cwise.
  • Create typed array for heatmap texture without calling flat (pick => shape 1D => unpack), or even without calling Float64Array.from (cwise + push to buffer). - no longer calling flat
@loichuder
Copy link
Member

WIP at #178.
Waiting for cwise to support recent ES versions to go further (scijs/cwise#25).

@loichuder loichuder added the waiting Waiting for another task to be completed label Jun 15, 2020
@axelboc
Copy link
Contributor Author

axelboc commented Sep 16, 2020

I think #198 brings us to a good state. The cwise optimisations no longer seem relevant anyway. There are still a few places where the code could be optimised (e.g. findDomain called twice with log scale and negative/positive domain, two uses of findDomain(values.filter()) which amounts to two loops, etc.), but I don't think the gain would be worthwhile when compared to the increase in code complexity.

@axelboc axelboc removed the waiting Waiting for another task to be completed label Sep 16, 2020
@loichuder
Copy link
Member

There are still a few places where the code could be optimised (e.g. findDomain called twice with log scale and negative/positive domain, two uses of findDomain(values.filter()) which amounts to two loops, etc.), but I don't think the gain would be worthwhile when compared to the increase in code complexity.

Yes, I think the performance is not an issue right now: things are running quite smoothly. Let's wait until we get more complains on that 😄

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

Successfully merging a pull request may close this issue.

2 participants