Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I sped up serde_json strings by 20%

purplesyringa.moe

Post reply on HN
Print view View original

51–60 of 124 posts

Re: I sped up serde_json strings by 20%

#51

Post by wiseowise »

haberman wrote: post #44
SkiFire13 wrote: post #33

Earlier quoted context omitted.

Let's be real about dependencies https://wiki.alopex.li/LetsBeRealAboutDependencies

> A medium-sized Rust project can easily tip the scales at 2-300 crates, which is still rather more dependencies than anything I’ve looked at here, but that’s explained by the simple fact that using libraries in C is such a monumental pain in the ass that it’s not worth trying for anything unless it’s bigger than… well, a base64 parser or a hash function. It's odd that this article spends so much time arguing that Ru…

Because Rust has Cargo which makes it trivial to include dependencies.

C developers constantly reinvent because C dependency management is such a joke that no one bothers.

Re: I sped up serde_json strings by 20%

#52

Post by IshKebab »

purplesyringa wrote: post #12
zadokshi wrote: post #3

Serde json has 3gb of dependencies once you do a build for debug and a build for release. Use serde on a few active projects and you run out of disk space. I don’t know why json parsing needs 3gb of dependencies. I’m all for code reuse but Serde for json is a bit of a dogs breakfast when it comes to dependencies. all you need is an exploit in on of those dependencies and half of the rust ecosystem is vulnerable. Rust…

> Rust should have Jason built in. I don't think this is a reasonable approach. That's just a way to introduce bloat. Importantly, std does not differ from other crates, except for stability guarantees, so there would be no positive here. All it does is link the library's release cycle to the compiler's. (In fact, rustc-serialize used to be built-in, so Rust tried to go that way.) But also, serde_json isn't large by…

Std definitely differs from other crates:

1. There's only one version so you can't end up with multiple copies of the crate.

2. It is precompiled, so it doesn't bloat your target directory or compile time.

3. It is able to use unstable features without using the nightly compiler.

It's a totally reasonable approach. Many other languages have JSON support in their standard libraries and it works fine. I'm not sure I'd want it, but I wouldn't say it's an obviously bad idea.

Re: I sped up serde_json strings by 20%

#53

Post by wiseowise »

runevault wrote: post #32
echelon wrote: post #29

Earlier quoted context omitted.

> The dependency trees for any meaty Rust project quickly become pretty horrifying. s/Rust// This is really no different from any other language. At least Rust, with Cargo, makes it easy to scan your dependencies. And many notable Rust projects attempt to keep third party dependencies to a minimum. C++ gives you absolutely nothing to work with. Other languages with package managers don't keep dependency trees shallow…

I'm not sure languages without a package manager being the default are nearly as bad. When it is trivial (like running a single command line or a single line in a file like cargo.toml), having a proliferation of dependencies is so easy it almost becomes guaranteed. But in languages like c++ where not everyone uses them (even if several PMs exist) adding a dependency to a library is a much bigger deal as you either ha…

[flagged]

Re: I sped up serde_json strings by 20%

#54

Post by hsbauauvhabzb »

Sytten wrote: post #20

The utf-8 tricks make me very nervous since I have seen too many attacks with parser confusion. I for with serde for correctness not speed. I hope this was fuzzed all the way with a bunch of invalid utf-8 strings.

Any bugs you can point to that come to mind of this class?

Re: I sped up serde_json strings by 20%

#55

Post by tcfhgj »

wiseowise wrote: post #50
throwup238 wrote: post #19

Earlier quoted context omitted.

Almost nobody is shopping around Rust JSON libraries unless they need some specific feature not provided by serde and serde_json. They are the default everyone reaches for.

The moment you NEED to include a library to parse some basic JSON file - you’ve lost already.

Why have I lost what exactly?

Re: I sped up serde_json strings by 20%

#56

Post by DougBTX »

wiseowise wrote: post #49
purplesyringa wrote: post #12

Earlier quoted context omitted.

> Rust should have Jason built in. I don't think this is a reasonable approach. That's just a way to introduce bloat. Importantly, std does not differ from other crates, except for stability guarantees, so there would be no positive here. All it does is link the library's release cycle to the compiler's. (In fact, rustc-serialize used to be built-in, so Rust tried to go that way.) But also, serde_json isn't large by…

> I don't think this is a reasonable approach. That's just a way to introduce bloat. Can this meme die already? The fact that out of the box install of Rust can’t parse JSON is a joke, and you know it.

Rust has a great package manager, so moving libs into std doesn’t bring much benefit.

On the other hand a change like this perf improvement can be released without tying it to a language version, that’s good too.

Re: I sped up serde_json strings by 20%

#58

Post by loa_in_ »

what wrote: post #37
ComputerGuru wrote: post #36

Earlier quoted context omitted.

That’s not the size of the program but the size of the build artifacts folder that includes all the intermediate files like .o in a C project and more.

That still seems like a lot of build artifacts for a 10 line program?

It deserializes a unicode string to a custom structure. Do not mistake it with C character-shuffling hello-world-programs.

Edit: s/to JSON/to a custom structure/

Re: I sped up serde_json strings by 20%

#59

Post by carlmr »

wiseowise wrote: post #51
haberman wrote: post #44

Earlier quoted context omitted.

> A medium-sized Rust project can easily tip the scales at 2-300 crates, which is still rather more dependencies than anything I’ve looked at here, but that’s explained by the simple fact that using libraries in C is such a monumental pain in the ass that it’s not worth trying for anything unless it’s bigger than… well, a base64 parser or a hash function. It's odd that this article spends so much time arguing that Ru…

Because Rust has Cargo which makes it trivial to include dependencies. C developers constantly reinvent because C dependency management is such a joke that no one bothers.

This is so on-point. Number of dependencies is correlated with ease of package management.

If you have a well-working package manager you're more likely to use a dependency than just rewrite that little part of your code.

For little programs written in C or C++ this usually means that people write their own buggy CLI parsing that doesn't produce a proper help message and segfaults with the wrong combination of arguments. In Rust people use clap. And they just need to derive on their CLI arguments struct.

And this process happens for every "small" dependency. In the end you're faster developing with cargo, you get a more professional result, probably you can even generate an executable for ARM and Intel without changing anything.

But OMG, you have a dependency tree.

Re: I sped up serde_json strings by 20%

#60

Post by loa_in_ »

zorked wrote: post #57

> Teaching to _think_ is just as important as teaching to code, but this is seldom done Oh, the arrogance of thinking that the other person doesn't think.

It isn't what author argues at all. It's about teaching how to think: that you have to do some research and it's not a step you can skip; having done your research doesn't free you from having to draw your own conclusions too. Skipping either of those steps is easy but wrong.
Post reply on HN