Document performance increase from not using NanoDate()
See original GitHub issueThe Usage page states that,
The exception is if you manually ask for a precision of
ms
or coarser in the options parameter of Influx#query method. Then, we parse your times into normal Dates.
For certain classes of applications, nanosecond-precision is overkill. Since performance is a focus in v5, it would be interesting to document the potential gains coming from sticking with Date
s.
Issue Analytics
- State:
- Created 7 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Is there any way to get current time in nanoseconds using ...
"The performance.now() method returns a DOMHighResTimeStamp, measured in milliseconds", according to the link you posted. Milliseconds are not nanoseconds. – ...
Read more >Enhancement for Date, Time, Timestamp that can improve ...
You can code VALIDATE(*NODATETIME) to improve the performance of some Date, Time, Timestamp operations (but use with caution).
Read more >What's New — pandas 0.8.1 documentation
This release includes a few new features, performance enhancements, and over 30 bug fixes from 0.8.0. ... All objects can now work with...
Read more >Entity Annotations - ObjectBox Docs
Learn how to persist entities with entity annotations in this tutorial section. ... Entities must have a no-args constructor, or for better performance, ......
Read more >The journey to support nanosecond timestamps in Elasticsearch
It's not only the common log file case, which most of the time is fine with milliseconds, but think of the manufacturing industry, ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Published in
5.0.0-alpha.2
, available undernpm install --save influx@next
I’ve managed to squeeze it down to a 11 - 14% difference. This is acceptable, I think, a good tradeoff for a more consistent API. If people can’t afford that hit they probably should be using queryRaw instead. Still parses well over 3 million rows/sec on my machine.