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
