Re: Strange inefficiency

[Elliot Lee <sopwith redhat com>]

On Mon, 22 Jan 2001, Michael Meeks wrote:

> 	Ok; so I just looked at our printing interface and realized
> something rather frightening - that I'd have to re-design it because
> of brokenness in ORBit. It is also rather a concern for the
> performance of our block IO routines.
>
> 	So; in the stub ( or skel ) for marshalling a sequence of
> octets I see:
>
> {
> 	guchar *p;
>
> 	p = alloca(sizeof((*buffer)._length));
> 	memcpy (p, &((*buffer)._length), sizeof((*buffer)._length));
> 	giop_message_buffer_append_mem(
> 		GIOP_MESSAGE_BUFFER (_ORBIT_send_buffer), p,
> 		sizeof((*buffer)._length));
> }
>
> 	So; I can perhaps understand the purpose of this code in the
> following situations:
>
> 	a) A multi-threaded or asynchronous environment[1]
> 	b) With small sequences ( iovec merging will speed things up )
>
> 	However; a) is not true of ORBit / this application and b)
> cannot be true for large blocks of data - 4K+ or so.
>
> 	So; I have a single (2.5Mb) dynamicaly allocated area on the
> I even dup this in memory ( ignore this foolishness for now ), so
> then I return it from my impl to the skel.
>
> 	The skel promptly tries to alloca 2.5Mb and has a fit.

That's definitely not the code that is doing it -
sizeof((*buffer)._length) is going to be 4 bytes.

-- Elliot
Who me? I just wander from room to room.