GNOME Bugzilla – Bug 640729
Unnecessary blank spaces in generated JSON even with pretty-print disabled
Last modified: 2012-03-13 22:08:24 UTC
The generator always produces JSON with blank spaces to separate some data tokens, even when "pretty" property is false. e.g: "[ 1, 2, 3 ]" -> 4 blank spaces "[ {"foo" : null}, {"bar" : null} ]" -> 7 blank spaces This is unnecessary if there is already a "pretty" version with proper indentation and spacing, intended to be easily readable by humans. These blanks are undesirable when JSON is to be consumed by a computer, like for example when used to build protocols or any case where JSON is put on a wire. Bug is about removing these blank spaces in generated JSON, when "pretty" property is disabled.
Created attachment 179440 [details] [review] patch to fix it This patch shall fix this. Affected tests were updated. In some test cases that were updated, it is very noticeable how much the length of the JSON string is reduced, just by stripping the unnecessary blanks.
Any comment on this? In my use case I have to move generated JSON over a network connection and I'm losing precious bandwidth with those blanks :(. Any chance to have this at least discussed? cheers
Review of attachment 179440 [details] [review]: I'm not entirely convinced that a bunch of spaces are going to have that big of an impact on bandwidth; if you're really sending/receiving that amount of data, I'd suggest using a compression module on the web server, and passing through an InputStream to uncompress the data. on the other hand, I don't have that much of an issue with the patch in and of itself, except that it makes debugging slightly more difficult. anyway, feel free to commit to master.
(In reply to comment #3) > Review of attachment 179440 [details] [review]: > > I'm not entirely convinced that a bunch of spaces are going to have that big of > an impact on bandwidth; if you're really sending/receiving that amount of data, > I'd suggest using a compression module on the web server, and passing through > an InputStream to uncompress the data. Well, it depends on the amount of that to be moved. For small JSON messages probably the HTTP headers or other transport overheads make this unworthy, but as the length of the message increases, the penalty is noticed. Compression does help, but at the cost of performance. My rationale is that having the blanks is unnecessarily suboptimal. > anyway, feel free to commit to master. Pushed to master, thanks.
[Fixing Default QA assignee for json-glib - see 613232#c1. Sorry for bugmail noise.]