From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA15235 for caml-redistribution; Thu, 1 Apr 1999 12:46:58 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA30680 for ; Wed, 31 Mar 1999 23:35:29 +0200 (MET DST) Received: from zarya.maya.com (zarya.maya.com [192.70.254.128]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id XAA12347; Wed, 31 Mar 1999 23:35:12 +0200 (MET DST) Received: (from prevost@localhost) by zarya.maya.com (8.8.7/8.8.7) id QAA31249; Wed, 31 Mar 1999 16:36:20 -0500 Sender: weis To: Xavier Leroy Cc: caml-list@inria.fr Subject: Re: Strange hugeness of .o, .cmo, and .cmi files References: <19990331175912.00500@pauillac.inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: John Prevost Date: 31 Mar 1999 16:36:20 -0500 In-Reply-To: Xavier Leroy's message of "Wed, 31 Mar 1999 17:59:12 +0200" Message-ID: User-Agent: Gnus/5.07008 (Pterodactyl Gnus v0.80) XEmacs/21.0(beta67) (20 minutes to Nikko) Xavier Leroy writes: > It's hard to say what's happening without seeing the source or the > generated assembly code. If that kind of things doesn't scare you, > just compile with ocamlopt -S and look at the resulting .s file. > However, I'll venture a guess: The source is almost exactly as you see, for the most part. I can package it along to you if you'd like. The start of the notably huge part of the .s file is at the end of this message. > OCaml 2.01 had a known code size problem with the > { record with lbl = newval } construct, when "record" belongs to a > type with many labels. This was fixed in OCaml 2.02, however. I've been using 2.02 nearly since it came out, so it's not a 2.01 vs 2.02 problem. All I'm doing is: let get_bool e n = try e.booleans.(n) with _ -> false let get_number e n = try let contents = e.numbers.(n) in if contents = -1 then None else Some contents with _ -> None let get_string e n = try let start = e.strings.(n) in if start = -1 then None else let finish = String.index_from e.string_table start '\000' in Some (String.sub e.string_table start (finish - start)) with _ -> None let process_entry e = let get_bool = get_bool e in let get_number = get_number e in let get_string = get_string e in { auto_left_margin = get_bool 0; auto_right_margin = get_bool 1; no_esc_ctlc = get_bool 2; [ ... for 463 total lines ... ] enter_right_hl_mode = get_string 389; enter_top_hl_mode = get_string 390; enter_vertical_hl_mode = get_string 391 } I'd guess from the below that it's for some reason making a long entry in the frametable for each one of the lines above. I don't know enough about how ocamlopt generates code to know what that means. John. Partial .s file: Terminfo_frametable: .long 502 .long .L648 .word 4 .word 0 .align 4 .long .L646 .word 16 .word 1 .word 8 .align 4 .long .L645 .word 12 .word 1 .word 0 .align 4 .long .L644 .word 12 .word 1 .word 0 .align 4 .long .L643 .word 12 .word 0 .align 4 .long .L642 .word 12 .word 0 .align 4 .long .L640 .word 12 .word 0 .align 4 .long .L639 .word 12 .word 1 .word 4 .align 4 .long .L638 .word 12 .word 1 .word 0 .align 4 .long .L636 .word 1852 .word 462 .word 0 .word 4 .word 12 .word 16 .word 20 .word 24 .word 28 .word 32 .word 36 .word 40 [ ... counting up by 4 to ... ] .word 1844 .word 3 .align 4 .long .L633 .word 1852 .word 461 .word 0 .word 4 .word 12 [... again, counting down the .word 461 until it is .word 1, with one less entry after each time... ] [... a few more smaller bits... ...]