Eliminate code generation for Struct methods #13
Conversation
Struct.to_binary, Struct.parse_value and Struct.parse_binary were doing code generation to produce and store a specialised method for each struct instance. Apparently (see python-xlib#12) this was a necessary optimisation in the distant past, but it's almost certainly no longer needed, and it makes the code considerably harder to follow. On my machine the tests run slightly but noticeably faster with this change, but of course the tests are probably not a realistic sample for performance testing. This doesn't directly impact Python 3 support, but it simplifies things.
Current coverage is
|
|
That was quick turnaround! Does the tests perform repeated packs/unpacks of the same structure? If it tests each struct a single time, it makes sense that this code runs slightly faster since it saves on the code generation. |
|
I haven't written any new tests, and I guess that the existing tests are dominated by handling each kind of struct only once, so they're definitely not representative. I would definitely expect there to be some performance hit when using the same structs repeatedly. Are any of the examples in the repo likely to be useful for performance testing? |
|
draw.py and shapewin.py might be candidates, as they are interactive. |
|
Wouldn't a non-interactive example be a better candidate? I'm playing with draw.py a bit, but any variation in what it does is dominated by variation in the user activity, so I'm not sure how to get any comparable numbers out of it. |
|
I also vote for simplicity in this code. If there are no objections, I'm going to merge it tomorrow. |
Eliminate code generation for Struct methods
4 participants
Struct.to_binary,Struct.parse_valueandStruct.parse_binarywere doing code generation to produce and store a specialised method for each struct instance. Apparently (see #12) this was a necessary optimisation in the distant past, but it's almost certainly no longer needed, and it makes the code considerably harder to follow.On my machine the tests run slightly but noticeably faster with this change, but of course the tests are probably not a realistic sample for performance testing.
This doesn't directly impact Python 3 support, but it simplifies things.