Uh oh!
There was an error while loading. Please reload this page.
Convert json Reader to iterators - #7704
Conversation
This is much faster for strings, and eventually when there is a buffered reader of some sort. Reading example.json 100 times before was around 1.18s. After: - reading from string 0.68s - reading from file 1.08s (extra time is all in io::Reader)
huonw
commented
Jul 11, 2013
Looks awesome, but is there a particular reason this uses |
This is much faster for strings, and eventually when there is a buffered reader of some sort, will be much faster for files. Reading example.json 100 times before was around 1.18s. After: - reading from string 0.68s - reading from file 1.08s (extra time is all in io::Reader) Also: - fixes#7611 - error when parsing strings and we hit EOF - updates definition of whitespace in json should only be the 4 ascii whitespace chars
glinscott
commented
Jul 11, 2013
@huonw: no - that is due to my lack of experience in rust. I tried removing the ~ and it compiles fine, and the speed remains the same. From a semantic point of view, will that not cause a copy of T though? |
huonw
commented
Jul 11, 2013
The Most iterator objects are fairly small so the copies (with plain |
…shearth Tweak pedantic description for occasional FPs changelog: none Okay this is getting a bit picky (you might even say pedantic). I think we need to be careful not use the pedantic category as cover-all for lints with any amount of false positives. Lints with a high degree of FPs should be nursery or restriction IMO. If the pedantic category were to yield, say hypothetically, over 50% FPs, it would just be too annoying to use at all (to be sure, "too picky for me" is not a FP). CC `@rust-lang/clippy`
7704: Avoid transmitting unchanged diagnostics r=matklad a=michalmuskala Reading through the code for diagnostics and observing debug logs, I noticed that diagnostics are transmitted after every change for every opened file, even if they haven't changed (especially visible for files with no diagnostics). This change avoids marking files as "changed" if diagnostics are the same to what was already sent before. This will only work if diagnostics are always produced in the same order, but from my limited testing it seems this is the case. Co-authored-by: Michał Muskała <michal@muskala.eu>
This is much faster for strings, and eventually when there is a
buffered reader of some sort, will be much faster for files.
Reading example.json 100 times before was around 1.18s.
After:
Also: