Now try parsing Rust in 500 lines of JSON
Parsing JSON in 500 lines of Rust
21–30 of 59 posts
Re: Parsing JSON in 500 lines of Rust
#22Here is one in 73 lines of F# by Jon Harrop: https://gist.github.com/isaksky/6681cfad8ced1708a04b2eca92fc...
I love how in F# you can express many concepts with simplicity. Thanks for the example.
Re: Parsing JSON in 500 lines of Rust
#23Parsing JSON is a Minefield:
https://seriot.ch/projects/parsing_json.html
Re: Parsing JSON in 500 lines of Rust
#24Regarding the 'sudo' issue: Doing a benchmark by just running an example executable is not really recommended because there's a ton of reasons why you might get differing performance.
It's probably better to set up an actual benchmark using a crate like Criterion instead [0].
Re: Parsing JSON in 500 lines of Rust
#25I guess it's faster with sudo because the regular account has some resource limits, or something? Didn't mention which system is being used (Linux? macOS? Something else?) but I can't repro on my Linux system, where performance is identical:
% cargo run --release
[..]
Parsing speed: 103761177.00 Bytes/s
Parsing speed: 103.76 MB/s
Parsing speed: 0.10 GB/s
% doas cargo run --release
[..]
Parsing speed: 105401032.21 Bytes/s
Parsing speed: 105.40 MB/s
Parsing speed: 0.11 GB/Re: Parsing JSON in 500 lines of Rust
#26Regarding the 'sudo' issue: Doing a benchmark by just running an example executable is not really recommended because there's a ton of reasons why you might get differing performance. It's probably better to set up an actual benchmark using a crate like Criterion instead [0]. [0] https://github.com/bheisler/criterion.rs
It's fine for things like this where you want to get a rough performance indication to see on what order of magnitude things are at (~1MB/s vs. ~10 vs. ~50 vs. ~100). A few percent error margin is fine for that.
Tools like that are to eliminate noise and variation, which is an entirely different issue. According to the article, "sudo" is about 70% faster. That has nothing to do with the benchmarking method.
Re: Parsing JSON in 500 lines of Rust
#27match object(src) { Ok(res) => return Ok(res), Err(JSONParseError::NotFound) => {} // if not found, that ok Err(e) => return Err(e), } You probably have realized that this is really tedious, and this is where macros would really shine: macro_rules! try_parse_as { ($f:expr) => ( match $f(src) { Ok(res) => return Ok(res), Err(JSONParseError::NotFound) => {} // if not found, that ok Err(e) => return Err(e), } ); } try_p…
Another article on the front page is discussing the capabilities of AI for coding. I wonder, given a 500 line problem, can any of the current cutting edge AIs make the code obviously, dramatically better? How far can they go?
Re: Parsing JSON in 500 lines of Rust
#28I once (maybe a long time ago?) made a parser for JSON by: 1. Reading the entire file into RAM. 2. Providing a `const char *get_value(const char *jstring, const char *path, ...)` function with a NULL-terminated parameter list that would return the position of the value of the key at the specified path. 3. Providing a `copy_value(const char *position)` function to copy the value at the specified position. Slow? Yup! B…
Only safe and easy if json file fits into the RAM.
Re: Parsing JSON in 500 lines of Rust
#29Regarding the 'sudo' issue: Doing a benchmark by just running an example executable is not really recommended because there's a ton of reasons why you might get differing performance. It's probably better to set up an actual benchmark using a crate like Criterion instead [0]. [0] https://github.com/bheisler/criterion.rs
It's fine for things like this where you want to get a rough performance indication to see on what order of magnitude things are at (~1MB/s vs. ~10 vs. ~50 vs. ~100). A few percent error margin is fine for that. Tools like that are to eliminate noise and variation, which is an entirely different issue. According to the article, "sudo" is about 70% faster. That has nothing to do with the benchmarking method.
It could eliminate issues where startup time and background scanning processes might interfere with initial throughput, though? Even things like CPU throttling could be affecting the test somehow. The main goal is to eliminate as many variables as you can.