From: SourceForge.net <no...@so...> - 2006-12-22 19:36:40
|
Bugs item #1152612, was opened at 2005-02-26 22:17 Message generated for change (Comment added) made by pedronis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112867&aid=1152612&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: Deferred Status: Open Resolution: None Priority: 2 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: vars(obj) returns PyStringMap instead of DictType Initial Comment: When getting an object's __dict__, the type() of the dictionary object returns PyStringMap. This causes a problem because types.DictType does not match PyStringMap. Some existing Marshallers (in my case, xmlrpclib) expect an Instance's __dict__ to be a DictType when marshalling an Instance (such as an Exception). It looks like types.DictType should match org.python.core.PyStringMap. When getting the __dict__ of an Instance in CPython, it returns a type of DictType. -Steve leo...@nu... ---------------------------------------------------------------------- >Comment By: Samuele Pedroni (pedronis) Date: 2006-12-22 19:36 Message: Logged In: YES user_id=61408 Originator: NO the issue is all the places that have an already interned String, not a PyString. String to PyString involve an allocation. Allocations are still costly. Whether using hashCode vs. identityHashCode, it is well possible that the performace trade offs of the two have changed over time since 1.1. Implementing identityHashCode is not straightforward on moving gcs. ---------------------------------------------------------------------- Comment By: leouser (leouserz) Date: 2006-12-22 19:30 Message: Logged In: YES user_id=1277399 Originator: NO hmmm, speed wise Im not sure, I guess it depends upon how quickly the PyString is going to return a hashCode call. From gutting PyStringMap and replacing it with a Map that used the interned strings I saw a boost in performance on the test I was running. So from that angle PyStringMap didn't seem that speedy. I would suspect that PyString would return as quickly as the String. Its hashCode, hashes the internal string and caches the value. So I would expect equivilent behavior between the two. Also, it looks like it should have a speedy equals method. As long as the string is interned. So I don't see any terrible issues using it as a key. I think using a PyDictionary would make the instances more compliant with Python. Given that I can take the dict from a Python instance and use non-strings for keys. leouser ---------------------------------------------------------------------- Comment By: Khalid Zuberi (kzuberi) Date: 2006-12-22 19:10 Message: Logged In: YES user_id=18288 Originator: NO The only (little) help i can add is to note Samuel's recent reference to performance & PyStringMap: http://article.gmane.org/gmane.comp.lang.jython.devel/2610 - kz ---------------------------------------------------------------------- Comment By: leouser (leouserz) Date: 2006-12-22 14:24 Message: Logged In: YES user_id=1277399 Originator: NO its possible that this could be fixed by just ditching the PyStringMap used internally and switching over to PyDictionary. From experimenting with gutting PyStringMap and replacing its internal arrays and hashing with a HashMap, I was able to get an increase in performance. Given that the Dictionary appears remarkable similiar to that implementation---> forwarding to its Hashtable(yuck), there may not be a performance reason to stick with the PyStringMap(assuming that is the reason that there is a PyStringMap). leouser ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112867&aid=1152612&group_id=12867 |