Closed juselius closed 2 years ago
Ah, you found perhaps the lowest hanging fruit it would seem :). Very nice.
You know, on second thought it might good to do the same thing on .NET too. The in-place reverse with Array.Reverse
is dirty because it mutates the input array if the system is little endian. I would not worry about threading issues on .NET because the Reader
type is not designed to be thread-safe (pos
is already a mutable instance property), though it would be problematic should we ever use parallelization during a single deserialization (in your original data model, both the integer and float arrays in a tuple could be processed simultaneously).
What do you think?
@kerams since multi-threading and parallelization isn't a concern, it's a trivial fix. Just remove the special case for !FABLE_COMPILER
, and it's done :) I'll make a new PR!
Shall I bump the version to 1.13.1 at the same time?
Shall I bump the version to 1.13.1 at the same time?
There's no need.
Thanks a lot @juselius and @kerams I will publish a new package soon!
@juselius A new batch of packages has been publishes that includes the improvement in MsgPack 🚀 updating Fable.Remoting.Client
should give you latest bits
readint ()
uses a local temporary array for endian conversion. This array gets created and garbage collected for every value, putting a lot of strain on the garbage collector. By making the array a reusable class variable, we achieve 3-4 times faster execution. The class variable is only used by Fable, and since JavaScript is single-threaded there should not be any issues related to race conditions etc.