|
Welcome the channel on the development of Cro, a set of libraries for building reactive distributed systems, lovingly crafted to take advantage of all the Raku Programming Language has to offer (cro.services). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
|
07:45
patrickb joined
07:50
patrickb left
08:23
patrickb joined
|
|||
| japhb | jnthnwrthngtn: You wanted to know as CBOR::Simple improved in performance. With the latest tuning, it now ranges from slightly slower in the worst case to much faster than JSON::Fast on the same data, while generally having smaller encoded size and better fidelity with original types. | 08:53 | |
| jnthnwrthngtn | japhb: Faster on numerics, I imagine? What's the main slower area? | 08:55 | |
| japhb | Oddly, round-tripping simple UNPACKED small Int Arrays -- CBOR tries to compress those extra well, and it costs. (About 30% slower decode, 55% slower encode on my machine.) Decode of data structures pulled from META6.json files is about 16% slower. Everything else is faster. | 08:59 | |
| Packed floats and blobs are ridiculously fast (orders of magnitude faster, since JSON can't do them natively and has to fall back to unpacked) | 09:00 | ||
| Haven't added the code for packed ints (they silently encode as unpacked ints, with a small speedboost from knowing they're all the same type) | 09:01 | ||
| *packed intarrays | |||
| jnthnwrthngtn | What about individual ints? | 09:04 | |
| japhb | Should be pretty quick, and small. | ||
| I would love to find more places to improve it, so if you have any particular data files you'd like to use as a challenge, I'm all ears. Happy to add them to my perf tuning collection, too. | 09:06 | ||
| (And if you have a use for packed intarrays sooner rather than later, I can prioritize that -- I've just been focusing on general performance for the last couple days) | 09:07 | ||
| jnthnwrthngtn: Here's a recent perf test run on my laptop, to give you an idea: gist.github.com/japhb/595d9afc9570...853f0c34a8 | 09:10 | ||
|
10:04
patrickb left
10:38
patrickb joined
|
|||
| jnthnwrthngtn | japhb: No, Log::Timeline doesn't currently make use of those | 12:19 | |
| japhb | Ah, that's what you want it for ... OK, do you have log entries from something performance-sensitive but not private (so you can share the entries and I can make a test)? | 18:35 | |
| I presume what you're looking for most is "Least time spent encoding each entry individually", but let me know if that's not right. | 18:36 | ||
|
18:38
sena_kun left
19:04
sena_kun joined
20:18
patrickb left
|
|||
| jnthnwrthngtn | japhb: The current protocol is JSONLines over a socket, but one can also set LOG_TIMELINE_JSON_LINES=filename in the environment to get that to a file, to see how the entries look | 21:03 | |
| japhb: Running a Cro web application with that in the environment and throwing some requests at it will get you some output. | 21:05 | ||
|
21:21
AlexDaniel joined
|
|||
| japhb | OK, SGTM | 21:56 | |