Network benchmark - header parsing

Miguel Barreiro enano@REDACTED
Sun Dec 14 18:17:46 CET 2003

> We are certainly interested in parsing headers efficiently. SIP
> headers should permit the same sort of optimization that's done with
> {packet,http} - in fact it doesn't look too hard to make something
> general in which the header names could be loaded after startup.
> What sort of header munging is the slow part for your inbound
> processing?

MPEG PES headers are binary and clearly intended to be processed in
hardware. As a short introduction, a PS ("program stream" - what you store
on a DVD, for instance) is a sequence of "packs". Each "pack" may contain
an almost arbitrary number of PES ("packetized elementary streams")
packets. The first packet in any pack may be a system header. Several
important values (system clock references) are stored on pack headers. The
catch is that pack headers contain no length information: you have to
read each packet (of variable length), parse it, and check whether you
have reached the end of the pack. To make things worse, clocks are stored
in a fashion as "most significant part in multiples of 900KHz split into
three parts: 3 bits here, 15 bits there, 15 bits there... least
significant part in multiples of 27MHz, up to 22 bits, over there... and
finally a variable amount of stuffing before actual video/audio payload".
Smoke at ISO meetings must be really funny.

It's not the same as parsing HTTP or SIP headers.

> I am favorably impressed with bit syntax performance, to put it
> mildly. But, reflecting on recent mention on this list about regexes,
> would a set of regexes-for-binaries ops would help speed things up?

In this case, it would save a fair number of matchings. It might be
worthwhile or not depending on relative efficiency to "normal"
bitsyntax matching.

More information about the erlang-questions mailing list