StudioInfinity/nanomath
2
0
Fork 0
Code Issues 8 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Nanomath very slow #43

New issue
Closed
opened 2025-12-15 16:29:38 +00:00 by glen · 3 comments
glen commented 2025-12-15 16:29:38 +00:00
Owner
Copy link

The recent benchmarking PR shows that nanomath performance is far worse than both pocomath and mathjs 15. After a bit of poking around, the leading suspect is ArrayKeyedMap, which is used in nanomath centrally in the TypeDispatcher, but not in pocomath or mathjs. Let's see what happens if we switch to some other indexing scheme.

The recent benchmarking PR shows that nanomath performance is far worse than both pocomath and mathjs 15. After a bit of poking around, the leading suspect is ArrayKeyedMap, which is used in nanomath centrally in the TypeDispatcher, but not in pocomath or mathjs. Let's see what happens if we switch to some other indexing scheme.
glen commented 2025-12-15 20:17:55 +00:00
Author
Owner
Copy link

OK, well, getting rid of the ArrayKeyedMap did not help. It seems to be the typing a value is now very slow; benchmarking a bunch of typings in nanomath is 25.6 milliseconds vs. in pocomath it is 0.01 milliseconds. Perhaps the issue is the fact that Types are proxied objects for the sake of the function-call syntax?

OK, well, getting rid of the ArrayKeyedMap did not help. It seems to be the typing a value is now very slow; benchmarking a bunch of typings in nanomath is 25.6 milliseconds vs. in pocomath it is 0.01 milliseconds. Perhaps the issue is the fact that Types are proxied objects for the sake of the function-call syntax?
glen commented 2025-12-15 21:35:46 +00:00
Author
Owner
Copy link

Hmm, removing the proxy and the derivation from built-in Function improved things, but only by a factor of two: the typing benchmark still takes 12 milliseconds. Trying to figure out what else it could be.

Hmm, removing the proxy and the derivation from built-in Function improved things, but only by a factor of two: the typing benchmark still takes 12 milliseconds. Trying to figure out what else it could be.
glen commented 2025-12-16 07:05:38 +00:00
Author
Owner
Copy link

Just whittled away on typing until it got within a factor of two of pocomath, then switched to cbrt and polynomialRoot, where there were two problems:

  • Some advance resolutions in the factories were in fact not resolving anything (i.e., returning the function that resolves at call time), so I made that a warning and I fixed all instances of it.
  • The type converter factories were not pre-resolving the functions they used, so they were running resolution on every conversion, which is dreadfully slow.

With these things fixed up, brought nanomath to somewhere between one-third the speed and just slightly slower than pocomath, depending on the particular benchmark and the relative weight in it of resolution (which nanomath is still slow at) and computation (where nanomath is essentially just as fast).

Just whittled away on typing until it got within a factor of two of pocomath, then switched to cbrt and polynomialRoot, where there were two problems: * Some advance resolutions in the factories were in fact not resolving anything (i.e., returning the function that resolves at call time), so I made that a warning and I fixed all instances of it. * The type converter factories were not pre-resolving the functions they used, so they were running resolution on every conversion, which is dreadfully slow. With these things fixed up, brought nanomath to somewhere between one-third the speed and just slightly slower than pocomath, depending on the particular benchmark and the relative weight in it of resolution (which nanomath is still slow at) and computation (where nanomath is essentially just as fast).
glen closed this issue 2025-12-16 07:05:54 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
ohm_parse
nano_speed2
nano_speed
benchmark
No results found.
Labels
Clear labels   
design

An issue identifying a design decision that must be made

  
feature

A new/improved behavior implemented by the project

  
maintenance

A necessary/desired refactor, dependency update, or other behavior-orthogonal task.

  
priority

An issue that should be resolved sooner than issues not so labeled.

  
testing

An issue concerning the testing system

No labels
design
feature
maintenance
priority
testing
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
StudioInfinity/nanomath#43
No description provided.