Strange inefficiency

[Michael Meeks <michael ximian com>]

Hi there,

	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.

	Consequently my questions are:

	a) Why are we doing this alloca / memcpy - it seems totaly
futile to me.

	b) Can we stop doing it altogether, or perhaps do some
sort of compare on the length first ?

	Of course; I'll have to re-engineer the code to use a
Stream, but this is small consolation if every byte going down
the stream is copied umpteen times as well.

	Regards,

		Michael.

[1] - and even then I would take a very dim view of a program that
invalidated memory that had been passed to an as yet uncompleted
function in another thread.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot