Re: 50 times longer to compile than copy

David Chase <chase@naturalbridge.com>
7 Nov 2000 12:59:40 -0500

          From comp.compilers

Related articles
50 times longer to compile than copy smnsn@my-deja.com (2000-11-04)
Re: 50 times longer to compile than copy ian@jawssystems.com (2000-11-05)
Re: 50 times longer to compile than copy vii@penguinpowered.com (John Fremlin) (2000-11-05)
Re: 50 times longer to compile than copy s337240@student.uq.edu.au (Trent Waddington) (2000-11-05)
Re: 50 times longer to compile than copy chase@naturalbridge.com (David Chase) (2000-11-07)
Re: 50 times longer to compile than copy Sid-Ahmed-Ali.TOUATI@inria.fr (Sid Ahmed Ali TOUATI) (2000-11-07)
Re: 50 times longer to compile than copy ONeillCJ@logica.com (Conor O'Neill) (2000-11-09)
Re: 50 times longer to compile than copy lex@cc.gatech.edu (Lex Spoon) (2000-11-09)
Re: 50 times longer to compile than copy christl@belinda.fmi.uni-passau.de (2000-11-09)
Re: 50 times longer to compile than copy jacob@jacob.remcomp.fr (jacob navia) (2000-11-09)
Re: 50 times longer to compile than copy vbdis@aol.com (2000-11-11)
| List of all articles for this month |
From: David Chase <chase@naturalbridge.com>
Newsgroups: comp.compilers
Date: 7 Nov 2000 12:59:40 -0500
Organization: Compilers Central
References: 00-11-034 00-11-038
Keywords: performance

Ian Kemmish wrote:


  > The record for this in my experience was the PostScript interpreter at
  > the heart of James Gosling's NeWS window system. This was a single
  > routine spread across, as I recall one C file and two header files
  > (containing executable code!), being two switch statements, one of
  > which had a case for every operator in the PostScript language. I'm
  > afraid I can no longer remember how big this routine was in lines or
  > bytes.


85k. I worked at Sun at the time, a friend of mine rewrote that
PostScript interpreter into more of a threaded code form so that it
could more easily be tinklered with and optimized. We had
"discussions" about this particular switch statement. It is also possible
that the compiler spent an inordinate amount of time searching for
the very best hash function for a non-dense switch; this was something
that I recall noticing some compilers doing at the time (the compiler
in question scaled the number of trials linearly with the number of
cases; for a non-dense 5000-case switch, this can get pretty costly.
What I recall finding was that within about 20 tries the hash function
was about as good as it would get.)


David Chase
chase@naturalbridge.com


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.