Open nayr7 opened 1 year ago
Issue with openArray
is that it cannot be a parameter for async procs (Since it cant be guaranteed that the array/seq it is pointing to will still be alive). Could use something like an Iterable
concept that kinda achieves the same effect (Although it would increase the binary size if used with lots of different array sizes).
The reason for the string conversion is because of the use of jsony
, could switch to jsonutils
. While it isn't faster in benchmarks, not needing to convert to/from strings could make it faster (Another benefit, jsonutils
has better error messages).
Has with most API clients, biggest slowdown will be network. Would be good to analyse refactoring requester.nim
to use a pool of clients instead of creating a new one everytime to see if it gives lower latency
Rest of the suggestions seem good though :rocket:
Consider the following snippets:
Example 1:
and just about anything that use
fromJson
but cannot take inJsonNode
sExample 2:
... but we can do even better:
... which brings us to
openArray
and otherstring
ing shenanigans :sink
andopenArray[char]
in the code when possibleJsonNode
instead of converting them to string which is surely a way too costly operation for functions that run as often asnewMessage
profiling as we go
The main trap of optimizing stuff is that we think we are making things faster when in fact we are making them slower, every change must come with microbenchmark to ensure we are not shooting ourselves in the foot