Packet optimisation and small tweaks

[k-danil]

Good day and Happy new year!

This patch introduce changes in packet struct and some minor optimisations:

• Packet header embedded in packet by value not by reference. Packet header is mandatory part of packet, so we can cutoff expenses on addition heap allocation.
• Sort fields in Packet Adaptation Field by memory size. This optimisation cut some bytes on allocation of Packet Adaptation Field by better field alignment.
• Return custom parser in isPSIComplete(). It may be useful for someone, so be it.
• In packetPool.add replace multiple map access with one.
• In hasDiscontinuity & isSameAsPrevious call len(ps) once.
• In programMap use RWMutex, as we read much more than write.

Current benchmarks:

BenchmarkParsePacket
BenchmarkParsePacket-8   	 5675138	       201.8 ns/op	     416 B/op	       9 allocs/op
PASS

BenchmarkDemuxer_NextData
BenchmarkDemuxer_NextData-8   	  231079	      4485 ns/op	    6666 B/op	     125 allocs/op
PASS

After this patch:

BenchmarkParsePacket
BenchmarkParsePacket-8   	 5838757	       193.7 ns/op	     388 B/op	       8 allocs/op
PASS

BenchmarkDemuxer_NextData
BenchmarkDemuxer_NextData-8   	  248532	      4371 ns/op	    6458 B/op	     122 allocs/op
PASS

Also i'd like to ask for your advice.
Right now hottest part of demuxer (by profiler) is packet parser. It allocates slices for payload and structs for packet itself.
First. I think we can make use of sync.pool in packet creation process where we get new packet from pool and put them back by Packet.Close() method. By calling NextData we can put unused packets back in the pool for reuse, or if end user prefer NextPacket it can be called manually.
Second. We can allocate packet payload slice of size n*188 (where n is configurable via options) and then assign parts of it to sequential packets on demand. BytesIterator.DumpTo() will be implemented to copy on existent slice. It will minimise allocation count but underlying slice will not be collected by GC as long as even one of it's part still referred.
Third. In packet pool we make use of sync.Mutex. Are we provide multithread-safe guaranties for end users? Maybe we can get rid of it?

What do you think?

[barbashov]

Just curious: does that really make it run faster? If so, do you know why? :)

[k-danil]

It's hardly noticeable results. We can drop it off from current PR.

[k-danil]

Rolled back

[barbashov]

Do I get it right: you moved it to have better alignment?
Have you used some tool to help you with that optimization? (i.e. aligo)

[k-danil]

Yes it's alignment-base optimisation.
At first it was hand written, but i double check with structslop - didn't find any problem with my current scheme.
For notice it gave this result on current master:
struct has size 104 (size class 112), could be 96 (size class 96), you'll save 14.29%

[k-danil]

Hello, @asticode ! Is there any problem with this PR?

[asticode]

I don't really get the point of using the PacketsParser here 🤔 It shouldn't be used here

[k-danil]

The idea is too pass unwanted packets from accumulator as fast as possible (our personal case), but for this i have much more efficient solution. If you sure that this part is unnecessary or somehow dangerous, i will exclude it from commit and clean up packetAccumulator from PacketsParser related code.

[asticode]

Mmmm yeah I'd rather see it removed 👍

[k-danil]

Done.
For next PR i think of optional packet filter based on PacketHeader. This will cut unnecessary packets on early stages of pipeline.

[asticode]

I'm sorry I've been really busy at work recently. I've only one question (I've made a comment).