peterohler

10 ms·

61.
by peterohler 6y ago
Not according to this comparison https://github.com/ohler55/compare-go-json .
62.
by peterohler 6y ago
Have you compare it to OjG ( https://github.com/ohler55/ojg )? You could also add your parser to https://github.com/ohler55/compare-go-json .
63.
by peterohler 6y ago
While using git as an example is a bit over simplifying I agree with the comment. Over time, if you plan ahead, your build up a set of building blocks and at some point you can put together an application very quickly. I suppose it is all r
64.
by peterohler 6y ago
I think you are using the wrong building blocks. Build your own blocks or use ones that are solid with good test coverage and many of those issues go away.
65.
by peterohler 6y ago
DRY is something to strive for but as pointed out there are often tradeoffs with DRY. One that I ran into not too long ago when writing https://github.com/ohler55/ojg was the performance penalty that DRY code can incur
66.
by peterohler 6y ago
Couldn't agree more. If the code is going to be maintained by someone less experienced then KISS certainly is more helpful than DRY.
67.
by peterohler 6y ago
Working at home is great. It eliminates commute time so there is more time for life. I seriously doubt companies are going to willingly take a 20% cut in time they demand for a given salary. Most employers would thank that if someone gets m
68.
by peterohler 6y ago
A standing desk and a hot plate to keep a cup of tea warm. The desk keeps me moving and the tea being handy reduces trips to the kitchen.
69.
by peterohler 6y ago
Great article! As a performance dweeb, any information on how best to squeeze out a bit more performance is welcome. I might have to play with using panics in OjG ( https://github.com/ohler55/ojg ) and see if it gives a
70.
by peterohler 6y ago
One of my favorites as a kid. Of course it was on a 33 1/3 LP.
71.
WebSockets with GraphQL in Go the Easy Way(github.com)
6 points by peterohler 6y ago|0 comments
72.
OjC vs. Simdjson Racing Head to Head(github.com)
3 points by peterohler 6y ago|0 comments
73.
by peterohler 6y ago
The oj command in https://github.com/ohler55/ojg uses JSONPath as the query and filter language. Maybe it is more in line with what you are looking for.
74.
by peterohler 6y ago
Most of us have a day job and do this sort of thing for fun. I know that might seem weird to many but I think you will find most open source developers fall into that category.
75.
by peterohler 6y ago
The fastjson package is fast. Can't disagree but unfortunately it accepts invalid JSON and what you get from the parser is a Value that you can get values from using a Get() function and not a simple go type. To get a simple go type li
76.
by peterohler 6y ago
Nice explanation, thanks.
77.
by peterohler 6y ago
Shockingly different. The -O3 option made hardly any difference with OjC but more than a 10x difference with simdjson. I'll be removing the claim from the OjC readme. Thank you for being civil with your reply. Much appreciated.
78.
by peterohler 6y ago
The code example followed was in the simdjson basics.md. The example in the error handling example left off the realloc_if_needed argument which does default to true. I have updated the tests to be explicit that third argument is set for cl
79.
by peterohler 6y ago
The -O3 optimization is just an optimization. It made a 1% difference in performance. It's just something I had in the Makefile I copied.
80.
by peterohler 6y ago
I suspect the need to reallocate in simdjson is a factor in performance but that is really part of the benchmark. When using a parser it would be a very rare case to have the luxury of embedding the string to be parsed in the code. Usually
81.
by peterohler 6y ago
Have you tried running the tests with a pre-calculated length? When I made that change there was no noticeable difference. The iterations/msec went from 195 to 192 which is not statistically significant. I have no doubt a more complete
82.
by peterohler 6y ago
I tried to make the test realistic. Agreed that in a benchmark where the string is the same every time the length could be hard coded but in a real world scenario the length of a string is not known until you get the length. As for the leng
83.
by peterohler 6y ago
Benchmarks added at https://github.com/ohler55/ojc/blob/master/test/simdbench/RE...
84.
by peterohler 6y ago
Benchmarks have been added at https://github.com/ohler55/ojc/blob/master/test/simdbench/RE...
85.
by peterohler 6y ago
What I tried was getting each member of a parsed/loaded doc vs a single element. If I was using the library incorrectly my apologies. When I put the code up maybe you can give suggestions on how to make it more realistic. I will gladly
86.
by peterohler 6y ago
I was measuring extracting each piece of data in a JSON document on the assumption that all the data was needed as apposed to just a single field and then noting the time it took for each parser to complete. I will get the benchmarks code u
87.
by peterohler 6y ago
I'll get the code up on the OjC repo in the next day or two. You are right, there should be reproducible benchmarks to back up the statement.
88.
A Journey building a fast JSON parser and full JSONPath, Oj for Go(github.com)
4 points by peterohler 6y ago|1 comments
89.
by peterohler 6y ago
Just finished it last week. I'm pretty happy with the results but even more pleased with the JSONPath. It even works on regular types using reflection.
90.
by peterohler 6y ago
Interesting approach. A different approach was taken with OjG ( https://github.com/ohler55/ojg ) which shows a significant performance improvement over the current golang JSON parser.

More ›