How to convert bytearray into integer?
jacky.chao.wang at gmail.com
Mon Aug 16 21:08:34 CEST 2010
Thanks for your comments! Please check mine inline.
On Aug 17, 1:50 am, Thomas Jollans <tho... at 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
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.
> > 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.
More information about the Python-list