New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
json.dump much slower than dumps #56343
Comments
import json, timeit
obj = [[1,2,3]*10]*10
class writable(object):
def write(self, buf): pass
w = writable()
print('dumps: %.3f' % timeit.timeit(lambda: json.dumps(obj), number=10000))
print('dump: %.3f' % timeit.timeit(lambda: json.dump(obj,w), number=10000)) On my machine this outputs: I believe this is mostly caused by dump using JSONEncoder.iterencode without _one_shot=True, resulting in c_make_encoder not being used. |
This is indeed the case. And the solution is obvious: call dumps() and then write() the result yourself. If dump() used _one_shot=True, it would defeat the purpose of minimizing memory consumption by not buffering the whole result. |
I believe Antoine is saying “works as intended”, i.e. not a bug. I’m not sure it’s worth a doc change. |
Alright. I wouldn't mind a little note in the docs; I certainly did not expect that these two functions would perform so differently. Would it be very difficult though to add buffering support the C encoder? |
From just reading the docs, it appears that json.dump(obj,fp) == fp.write(json.dumps(obj)) and it is easy to wonder why .dump even exists, as it seems a trivial abbreviation (and why not .dump and .dumpf instead). Since, '_one_shot' and 'c_make_encoder' are not mentioned in the doc, there is no hint from these either. So I think a doc addition is needed. The benchmark is not completely fair as the .dumps timing omits the write call. For the benchmark, that would be trivial. But in real use on multitasking systems with slow (compared to cpu speed) output channels, the write time might dominate. I can even imagine .dump sometimes winning by getting chunks into a socket buffer and possibly out on the wire, almost immediately, instead of waiting to compute the entire output, possibly interrupted by task swaps. So I presume *this* is at least part of the reason for the incremental .dump. I changed 'pass' to 'print(bug)' in class writable and verified that .dump is *very* incremental. Even '[' and ']' are separate outputs. DOC suggestion: (limited to CPython since spec does not prohibit naive implementation of .dump given above) After current .dumps line, add "In CPython, json.dumps(o), by itself, is faster than json.dump(o,f), at the expense of using more space, because it creates the entire string at once, instead of incrementally writing each piece of o to f. However, f.write(json.dumps(o)) may not be faster." |
The name dump and dumps exist to match the same API provided by pickle and marshal. I agree that a note marked as CPython implementation detail should be added. |
Please don't add notes of this sort to the docs. |
Are you against the proposed wording or the note itself? Stating that in CPython json.dump doesn't use the C accelerations is a reasonable thing to do imho. |
Uh, talking about "CPython" is not very helpful here and only muddies |
With 'will try to ' and the next 'will ' omitted, I agree that Antoine's version is better than mine. |
dump() is not slower because it's incremental though. It's slower because it's pure Python. I don't think there is necessarily a memory/speed trade-off; it should be possible to write an incremental encoder in C as well. |
As Antoine and Eric stated, the module is working as intended and we don't document implementation details and generally stay away from talking about performance in the docs. |
json.dump uses the Python implementation of the json encoder instead of the C implementation. While this saves a bit of memory while dumping data, the performance impact is large: python/cpython#56343 Saving a user share with 3 million files to disk previously took 1 minute 13 seconds. It now takes 14 seconds. The C implementation of the json encoder doesn't support the 'indent' argument, so stop using it.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: