[interfacekit] Re: Portlink implementation

> Looking through Portlink source code, I saw it does (too) many copies of
the data (IMHO).
> For example, every time you add a byte/int/whatever, it creates a
PortlinkData object, it copies the data there, then adds that object to a
BList (which could involve a reallocation of the BList's buffer). When you
flush the data, the BList content is copied in a plain buffer (which is
allocated/deallocated every time), then the content of that buffer is
written to a port (I guess it involves another copy). I think this is just
overkill.
>
> Couldn't we just use a fixed buffer for portlink, and put the data
directly there?
> For example (note that there's no error checking here):
>
> Attach(const void *data, size_t size)
> {
>   memcpy(data, fBuffer + fSize, size);
>   fSize += size;
> }
>
>
> where fBuffer could be an array of 1024 bytes (a reasonable value, I don't
think we are going to write that much data at a time on a port)
>
> and then:
>
> Flush()
> {
>   write_port(fTarget, fOpcode, fBuffer, fSize);
>   fPos = 0;
> }
>
> It would be much simpler, much cleaner, and much faster.
> Just an idea. Comments are welcome :P

OK, then...

> Couldn't we just use a fixed buffer for portlink, and put the data
directly there?

    My answer would be NO. Why??? PortLink is by... "use" conception,
different from _BSession_.
    In PortLink architecture(witch I think is better than _BSession_) a
hole(big) message can be cached before sending it to... app_server.
    With _BSession_ this isn't so... natural, and not as... "good" I might
say.
Once a
message is more than 1024 bytes long... the app_server will have to WAIT for
the rest of the message, a thing, I find quite dangerous, if our application
crashes during that time; this would go in an confusion in one thread in
app_server and, the results in that window would be NULL.
    With PortLink... all things are beautiful, every command is cached, and
every command is *complete* when it reaches the app_server.

    Indeed PortLink does TOO many allocations, this should be fixed!!! But,
if we'll adopt your solution, MANY MANY changes should be made! Note here,
that PortLink is different is conception than _BSession_- that's why!
I was
planning to talk very soon this with DW, and I also had a solution. It goes
something like this:

* a simple linked list of the following structure
struct _BPage_{
    uint8    *ptrLocationOfAllocatedBuffer ( = new uint8[1024]);
    uint8    noOfBytesInBuffer
}

- when our message is bigger than 1024 bytes, we should allocate a new
_BPage_ add it to the list and write data into it just like you
said(directly).

Then when Flush(), we'll alocate a new buffer witch is equal with our
message size, copy all the data from _BPage_s into it and sent it to
app_server.

> Just an idea. Comments are welcome :P

    Likewise :P

BTW: Ingo! You said you'll supply us with a small library for using
simple/double liked lists, hash tables,... whre is it? :)


Adi.

Other related posts: