byroot

15 ms·

91.
by byroot 2y ago
I'd say sorbet largely adds to the mud, but to each their own.
92.
by byroot 2y ago
> knowingly (it's obvious) The term used in French isn't quite as strong as "obviously", it's "manifestement illegal". See Wordreference: https://www.wordreference.com/fren/manifes
93.
by byroot 2y ago
Probably not, but there would definitely be some sort of resistance, strikes, refusal to comply, etc. In France public service employees have a very high level of protection (they're very hard to fire), and are legally allowed to disob
94.
by byroot 2y ago
It is yes [0]. > You can turn an Array into an argument list with * (or splat) operator > You can turn a Hash into keyword arguments with the * (keyword splat) operator: It's also named spat across the MRI codebase, e.g. `VM_CALL
95.
by byroot 2y ago
I guess I really don't understand what you are trying to say.
96.
by byroot 2y ago
The lobste.rs maintainer kindly offered to collect data in production: https://github.com/lobsters/lobsters/pull/1442 I haven't taken the time to fully analyze the data, but surface level show lobster.rs
97.
by byroot 2y ago
I use simple logging code to show how the data is collected. In a real production setup, that timing would be reported into Datadog / NewRelic or whatever APM service, but collected in a similar way.
98.
by byroot 2y ago
That may be true for very memory constrained platforms like Heroku, but is a non issue at larger scale. Taking your figure of 300MiB per process, and assuming you might want to run 1.5 process per core to account for IO-wait, that's 45
99.
by byroot 2y ago
Someone else pointed the same thing on bluesky, so I guess this part of my post isn't very clear. First, I/O bound isn't necessarily a very well defined term, but generally speaking, it implies that you can't substantial
100.
by byroot 2y ago
There’s no policy. The person or team owning an open source repo does what they want. Some are very closely watched, some were mostly just meant as extraction and not really expecting outside contributions.
101.
by byroot 2y ago
Yes, JSON as a format is very much under specified, a lot of these sorts of things are basically implementation defined. In general libraries do what make sense in the context of their host language, or sometimes what makes sense in the con
102.
by byroot 2y ago
Yes that's what I meant. The benchmark suite I took from rapidjson was benchmarking against: Oj::Parser.usual.parse(string) That is what isn't thread safe. And yes you can implement a parser pool, or simply so something l
103.
by byroot 2y ago
Ah, I figured why on the Oj side `ruby/json` appeared slower: https://github.com/ohler55/oj/pull/949
104.
by byroot 2y ago
> If callback parsing is not supported that's fine. Yes, as mentioned in part 1 of the series, my goal for ruby/json, given it is part of Ruby's stdlib, is to be good enough so that the vast majority of users don't ne
105.
by byroot 2y ago
> Using the benchmarks in the Oj test directory I'm sorry, but I've looked for a while now, and I can't seem to identify the benchmark you are mentioning. I suspect it's the one John took for his benchmark suite? [0]
106.
by byroot 2y ago
Thanks https://github.com/byroot/byroot.github.io/commit/4527ae5948...
107.
by byroot 2y ago
You might be right. I'll try to remember to add a note on that.
108.
by byroot 2y ago
> I should point out that other Oj modes perform much better than the JSON gem Which modes are that? https://github.com/ohler55/oj/blob/develop/pages/Modes.md#oj... I tried: Oj.dump(obj, mo
109.
by byroot 2y ago
> Would allocating a 640-byte string initially really be the right tradeoff? It depends, presumably the generated JSON string would quickly be written down inside something else (e.g. sent as HTTP response or saved in database), so the o
110.
by byroot 2y ago
> At the time I wrote it, the unit tests told me that wasn't true Yes, it's something I changed before merging your patch. I didn't mean to say your patch wasn't good or anything It was very much appreciated.
111.
by byroot 2y ago
> The size of twitter.json has changed between the versions, I wonder why that is? For parsing benchmarks, it read the pretty formatted file that is committed in the repository. But for generation benchmarks it doesn't dump it prett
112.
by byroot 2y ago
> The example optimized code uses `String#each_char` which incurs an extra object allocation for each iteration You're right. To be closer to the real C code, I should have used `each_byte`, given the C code works with bytes and not
113.
by byroot 2y ago
There's quite a few more commits to go before the final result, but you can see it in the release notes: - https://github.com/ruby/json/releases/tag/v2.7.3 - https://github.com/ru
114.
by byroot 2y ago
I somewhat answered that in https://news.ycombinator.com/item?id=42450085 In short, since `ruby/json` ships with Ruby, it has to be compatible with its constraints, which today means plain c99, and no c++. There would
115.
by byroot 2y ago
It could be done relatively efficiently in C indeed, but it would be yet another option, imposing et another conditional, and as I mention in the post (and will keep hammering in the followups) conditions is something you want to avoid for
116.
by byroot 2y ago
Ah I see. TL;DR; it's possible, but lots of work, and not that huge of a gain in the context of a Ruby JSON parser. `ruby/json` doesn't use explicit SIMD instructions, some routines are written in a way that somewhat expects
117.
by byroot 2y ago
Not too sure what you mean by intrinsincs. The `json` gem is implemented in C, so it's a black box for YJIT (the reference implementation's JIT). The TruffleRuby JIT used to interpret C extensions with sulong so it could JIT acros
118.
by byroot 2y ago
Author here. Oj has an extremely large API that I have no intent on emulating in the default json gem, things such as "SAJ" (SAX style parsing), various escaping schemes etc. My goal is only to make it unnecessary for the 95% or s
119.
by byroot 2y ago
> One downside of this approach though is it takes a long time for our app to boot Another is that you're leaving a lot of memory saving on the table by not benefiting from Copy on Write.
120.
by byroot 2y ago
That's already what we effectively have. Since objects cannot be promoted to the old generation inside the request cycle, objects in the new gen are request allocated objects. So if we were to eagerly trigger a minor GC after a request

More ›