Re: [LAD] "enhanced event port" LV2 extension proposal

Dave Robillard wrote:

> Sigh. In /this case/ they are the same, because the data directly
> follows

Sort it out with gcc, not with me :)

And if you meant that event->buf is still a pointer, buf the value of
event->buf will always be (&buf)+1, then we will always have a pointer
dereference. Which is (slightly) less efficient and usually unnecessary.
If you define a type that passes large data, put the pointer in payload,
it will only have to be dereferenced for that particular event type.

And if you meant that it's "usually (&buf)+1 but not if data is large"
then we also need to check if we need to skip the (possibly
non-existent) data block or not.

As in:

if (event->buf == (char *)(1 + &event->buf))
{
  // data are in-place, skip then
  event += some_function_of(event->size);
}
else
{
  // data are somewhere else
  event += some_function_of(header_size);
}

In other words - just remove the pointer from the generic header, or
replace it with buf[], a zero-length in-place array, as opposed to 4- or
8-byte pointer - and nobody's hurt ;)

And by the way - maybe it would make sense to use some sort of
performance testing framework to check which event headers are faster
and how much impact does it really have?

If the difference on a gain plugin (or say, wave playback - to test
cache-intensive stuff) is within, say, 10%, with 256-sample buffers and
event density of 8 samples/event, then there's not much to argue about.

Krzysztof

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Nov 30 16:15:02 2007