3 ms·
I feel like i'm missing something. In the "Why" section he claims that Rust is a performant language with a low-level feel. In this part, he claims that decod
by Artlav 10y ago
I feel like i'm missing something.
In the "Why" section he claims that Rust is a performant language with a low-level feel.
In this part, he claims that decoding a tiny JPG image took 2 seconds with his code.
How is that "performant" by any definition?
- pcwalton 10y agoMany language implementations generate code with good performance. That does not mean that all programs written in those languages will exhibit good performance.
- ape4 10y agoMake it work, then optimize.
- dbaupp 10y agoA language allowing high performance code doesn't mean it automatically guarantees high performance code. The latter is essentially impossible. One common pitfall is not turning the optimiser on (with --release for cargo) i.e. benchmarking a debug build rather than a release one, and from a quick glance this code looks like it may be doing a system call to read each and every byte of the file due to the use of .bytes() on an unbuffered file, whereas it would be better to use, say, read_to_end to read many bytes of the file at once.
- balducien 10y agoSomebody on reddit found the bottleneck: https://www.reddit.com/r/rust/comments/4yinbt/writing_a_jpeg_decoder_in_rust_part_2/d6obz7r?context=2 https://www.reddit.com/r/rust/comments/4yinbt/writing_a_jpeg... After fixing it, it apparently runs in 100 ms.
- martinhath 10y agoIt's worth mentioning, those numbers are for my test program which only read a single file, using my and his implementations. In addition, the file read was 20MB. lena.jpeg is 90K.
- evmar 10y agoThe code reads the file into a big buffer and then does array operations to index into it, which seems like the opposite of what you want for a good decoder. Using iterators etc. will let you read the file incrementally and will avoid array bounds checking.
- martinhath 10y agoAuthor here. I am having some trouble reproducing the 2 seconds number, but with optimizations I'm getting around 1.5 seconds (without, I'm up to 5!), and as balducien mentions, /u/DroidLogician pointed out a _huge_ performance flaw in the file reading code. Writing bad code is easy in any language (as I just showed :) - writing _super_ performant code is only possible in some. EDIT: I made a pretty bad mistake while writing this comment, claiming that fixing the file reading code improved the speed of the decoder _a lot_, which was not true at all. In fact, the difference is barely (if at all) noticeable when decoding lena.jpeg. However, when reading a larger file, the improvement is definitely there. So sorry! Replying to HN comments while drinking and watching a movie turns out not to be a great idea after all :)
- Artlav 10y agoAh, ok. From the Reddit thread it sounds like you were using a 20MB file for the 2s result? From the article it sounds like the 2s result was for the 90Kb file, which would have been rather odd.