The followup: I've implemented a new StructView-object for 3.3a-trunk. The object takes and existing Struct-object and provides on-access unpacking. The breaking point where this object is faster than calling Struct.unpack seems to be somewhere around 12 fields in the format-string. Format strings with less fields expose too much overhead of entering the C-code and staying there a little longer to unpack all fields is actually faster. Having fifteen or more fields in a format-string seems unlikely and I'll therefor abandon the idea of providing this mechanism. 2011/6/14 Lukas Lueg <lukas.lueg at googlemail.com>: >> So I really can't see what harm it could do, except for >> maybe a tiny performance reduction in the case where you >> extract all the fields, or refer to extracted fields >> repeatedly. > > Referring to the view-object multiple times should not be a problem > since the object can create and hold references to the unpacked values > it created; remember that they are all immutable. >
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4