To: luther at dpt-info.u-strasbg.fr
Cc: bombadil at wanadoo.es, debian-ocaml-maint at lists.debian.org,
        lablgtk@kaba.or.jp
Subject: Re: lablgtk and slowness of examples
In-Reply-To: <20010608164336.A12804 at lambda.u-strasbg.fr>
References: <20010608103814.A32483 at fangorn.net>
	<20010608164336.A12804@lambda.u-strasbg.fr>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20010609010109W.garrigue at kurims.kyoto-u.ac.jp>
Date: Sat, 09 Jun 2001 01:01:09 +0900
From: Jacques Garrigue <garrigue at kurims.kyoto-u.ac.jp>
Lines: 26

> After some testing, you can try compiling to either bytecode or nativecode,
> and obtain a much faster start. you can do it with either :
> 
> ocamlopt -I +lablgtk -labels -o testgtk.opt lablgtk.cmxa gtkInit.cmx testgtk.ml
> ocamlc -I +lablgtk -labels -o testgtk lablgtk.cma gtkInit.cmo testgtk.ml

You should also add "-w s", to avoid all these silly warnings about the
return type being not unit. You can see it in the lablgtk script.

> Either version is much faster than the toplevel one. I don't know specially
> what is different here though.

That's very strange. Trees are built an order faster with the bytecode
compiled version rather than the toplevel one.
I also tried loading testgtk.cmo in the toplevel, and this is also
fast.

I have no idea why it is so. I always believed that the toplevel
compiled to bytecode exactly as ocamlc, and should provide the same
speed. This is certainly not a source code interpreter.
I'll have to ask Xavier about this one.

Jacques
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>