Shawn <swal...@opensolaris.org> added the comment: As I mentioned, there's also noticeable performance penalties on recent SPARC systems, such as Niagra T1000, T2000, etc. The degradation is just less obvious (a 10-15 second penalty instead of a 20 or 30 second penalty). While x86 enjoys no penalty at all (in my testing so far).
Here's an example of the data structure: { "packages":{ "package-name-1":{ "publisher":"publisher-name-1", "versions":[ [ "0.5.11,5.11-0.86:20080422T230436Z", { "depend":{ "require":[ { "fmri":"foo" }, { "fmri":"bar" } ], "optional":[ { "fmri":"baz" }, { "fmri":"quux" } ] } } ], ] } } } Now imagine that there are 45,000 package-name-x entries in the structure above, and that basically replicates what I'm writing. If I turn the above structure into a list of lists instead, the penalty is significantly reduced (halved at least). If I flatten the stack even farther, the penalty is essentially gone. The greater the depth of the data structure, the greater the penalty. As for priority, I wouldn't call this "end of the world", but it does create some unfortunate surprises for developers that rely on the json module. Given the long service lifetimes of SPARC systems (due to cost :)), I suspect this would be of benefit for a long time to come. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6594> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com