Hi Thomas, Thanks for your comments! Please check mine inline.
On Aug 17, 1:50 am, Thomas Jollans <tho...@jollybox.de> wrote: > On Monday 16 August 2010, it occurred to Jacky to exclaim: > > > Hi there, > > > Recently I'm facing a problem to convert 4 bytes on an bytearray into > > an 32-bit integer. So far as I can see, there're 3 ways: > > a) using struct module, > > Yes, that's what it's for, and that's what you should be using. My concern is that struct may need to parse the format string, construct the list, and de-reference index=0 for this generated list to get the int out. There should be some way more efficient? > > > b) using ctypes module, and > > Yeeaah, that would work, but that's really not what it's for. from_buffer > wants a writable buffer interface, which is unlikely to be what you want. Actually my buffer is writable --- it's an bytearray. Turning it into a R/O one make me to do extra effort: wrapping the bytearray into buffer(). My question is, this operation seems like to be much simpler than the former one, and it's very straightforward as well. Why is it slow? > > > c) manually manipulation. > > Well, yes, you can do that, but it gets messy when you're working with more > complex data structures, or you have to consider byte order. agree. :) > > > Are there any other ways? > > You could write a C extension module tailored to your specific purpose ;-) Ha, yes. Actually I've already modified socketmodule.c myself --- it's hard to image why socket object provides the interface: socket.recv_from(buf[, num_bytes[, flags]]) but forget the more generic one: socket.recv_from(buf[, offset[, num_bytes[, flags]]]) So do socket.send(...). > > > number = 1 > > 1.00135803223e-05 > > 1.00135803223e-05 > > 5.96046447754e-06 > > ----- > > > As the number of benchmarking loops decreasing, method c which is > > manually manipulating overwhelms the former 2 methods. However, if > > number == 10K, the struct method wins. > > > Why does it happen? > > struct wins because it's built for the job. > > As for the small numbers: don't take these numbers seriously. Just don't. This > may be caused by the way your OS's scheduler handles things for all I know. If > there is an explanation for this unscientific observation, I have two guesses > what it might be: > * struct and ctypes still need to do some setup work, or something > * somebody is optimising something, but doesn't know what they should be > optimising in the first place after only a few iterations. Agree. Thanks. - Jacky -- http://mail.python.org/mailman/listinfo/python-list
