From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA10442; Mon, 15 Apr 2002 13:44:09 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA07497 for ; Mon, 15 Apr 2002 13:44:08 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g3FBi6D00567; Mon, 15 Apr 2002 13:44:06 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA08137; Mon, 15 Apr 2002 13:44:05 +0200 (MET DST) Date: Mon, 15 Apr 2002 13:44:05 +0200 From: Xavier Leroy To: james woodyatt Cc: The Trade Subject: Re: [Caml-list] optimum class initializer functions? Message-ID: <20020415134405.A12556@pauillac.inria.fr> References: <07911903-4683-11D6-A682-000502DB38F5@wetware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <07911903-4683-11D6-A682-000502DB38F5@wetware.com>; from jhw@wetware.com on Tue, Apr 02, 2002 at 01:46:03PM -0800 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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