[Caml-list] optimum class initializer functions?

[Caml-list] optimum class initializer functions?

[james woodyatt]

everyone--

I've noticed that using a class where a module would suffice produces 
substantially larger native code objects.

I haven't looked closely enough to know all the details, but it looks 
like object creation costs about the same as record creation.  All the 
extra space appears to be in the class initializer functions and the 
static data they require.  Seems like a fair trade, but I still have 
questions.

	1) Is there any room for improvement in the space requirements of
	   class implementations generated by the compilers?

	2) Are there any idioms to avoid that greatly increase the space
	   requirements of classes without offering any benefit in time or
	   code maintenance?

If no ones wants to answer these question, then I suppose I will get 
around to investigating the issue myself after awhile.


--
j h woodyatt <jhw@wetware.com>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] optimum class initializer functions?

[Xavier Leroy]

> I've noticed that using a class where a module would suffice produces 
> substantially larger native code objects.

This has been my experience too, and is a bit of a concern for me.

> I haven't looked closely enough to know all the details, but it looks 
> like object creation costs about the same as record creation.  All the 
> extra space appears to be in the class initializer functions and the 
> static data they require.  Seems like a fair trade, but I still have 
> questions.
> 
> 	1) Is there any room for improvement in the space requirements of
> 	   class implementations generated by the compilers?

I can imagine a couple of simple changes that could reduce slightly the
size of the class initializer code.  But nothing drastic yet.

> 	2) Are there any idioms to avoid that greatly increase the space
> 	   requirements of classes without offering any benefit in time or
> 	   code maintenance?

Apparently, most of the overhead is present even for very simple
classes (object ... end, without inheritance), so I don't think the
programming style impacts code size significantly.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners