in reply to Re^2: Iteratively unpack structure from binary file ( ReadBytes, ReadFloat, ReadInt32 )
in thread Iteratively unpack structure from binary file

That's a lot of calls to read and unpack. It would be far faster to process at least record at a time, if possible.

Yup, but I like the memorable-self-documenting-english-worded-ness of the api ...

The OP can always streamline his API once he gets things working the way he wants

By the way, you forgot to specify endianness for the floating-point types.

Its deliberate as per the comments copied from pack docs , pack has more about it ... float/double are very very platform specific even if you specify endianess

I can't guess how it gets twisted across platforms so I leave it as is

perlpacktut recommends Convert::Binary::C :) I find "my api" (similar to what I saw in javascript/java/c#sharp ...) easier

  • Comment on Re^3: Iteratively unpack structure from binary file ( ReadBytes, ReadFloat, ReadInt32 )

Replies are listed 'Best First'.
Re^4: Iteratively unpack structure from binary file ( ReadBytes, ReadFloat, ReadInt32 )
by ikegami (Patriarch) on Oct 22, 2014 at 03:22 UTC

    Yup, but I like the memorable-self-documenting-english-worded-ness of the api ...

    It's a pretty incomplete API. You didn't even support the integer formats used by most communication protocols.

    As for memorable and self-documenting, all that's needed here is

    sub parse_myformat_rec { ... }

    That would be more meaningful and surely at least 10 times faster. If so, that's the difference between 6 seconds and 60 seconds when processing large files as is usually the case with such code.

    I can't guess how it gets twisted across platforms so I leave it as is

    So why did you go out of your way to write code that will read your integers on those platforms?

    perlpacktut recommends Convert::Binary::C :) I find "my api" (similar to what I saw in javascript/java/c#sharp ...) easier

    perlpacktut recommends Convert::Binary::C for C structs. Your API isn't easier at handling those; it's completely useless at handling alignment.

      It's a pretty incomplete API. You didn't even support the integer formats used by most communication protocols.

      And then what happened?

      As for memorable and self-documenting, all that's needed here is sub parse_myformat_rec { ... }

      Ah yes, dot dot dot, the correct answer

      That would be more meaningful and surely at least 10 times faster. If so, that's the difference between 6 seconds and 60 seconds when processing large files as is usually the case with such code.

      Ah yes, the master pedant is baiting the hook

      So why did you go out of your way to write code that will read your integers on those platforms?

      So you will have something to talk about

      perlpacktut recommends Convert::Binary::C for C structs. Your API isn't easier at handling those; it's completely useless at handling alignment.

      Bravo sir, you win