How to convert bytearray into integer?

[Jacky]

Hi Thomas,

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
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