Wireshark · Ethereal-dev: Re: [Ethereal-dev] packet-parlay.c takes a very long time to compile in Fedora Core 5

[Guy Harris <gharris@xxxxxxxxx>]

Jeff Morriss wrote:

> Has anyone else noticed that packet-parlay.c (in plugins/giop/) takes a 
> _very_ long time to compile?  I recently upgraded from Fedora Core 4 to 
> Fedora Core 5 and now it takes around 10 minutes to compile it (on my 
> 1.6 GHz Pentium 4); I seriously thought the compiler was hung it was 
> taking so long...
>
> Of course I have no clue how long it used to take and I don't have an 
> (easy) way to test this on other versions or platforms at the moment--is 
> anyone else seeing anything like this?

Not quite that bad, but it does take a significant amount of time to 
compile on OS X 10.4.6 (1.5 GHz PPC G4).  (Did the FC4 -> FC5 upgrade 
either GCC or the GCC options?  The compiler might be doing more 
aggressive optimization.)

packet-parlay.c is the biggest .c file, by a factor of 2:

	  108689 ./plugins/giop/packet-parlay.c
	   45810 ./epan/dissectors/packet-nbap.c
	   39782 ./epan/dissectors/packet-rnsap.c
	   26162 ./epan/dissectors/packet-ncp2222.c
	   24442 ./epan/sminmpec.c

		...

I've been wondering whether, given the difference between memory speeds 
and CPU speeds these days, dissectors based on a small simple 
interpretive language, so that you have an interpreter with a small(er) 
cache footprint and interpretive code with a small(er) cache footprint, 
would run as fast, or faster than, a C-language dissector?  (The 
interpretive language might be something like NetPDL:

	http://analyzer.polito.it/docs/dissectors/NetPDL.htm

compiled into compact binary code.)  A lot of the code in the Parlay 
dissector appears to be a bunch of nearly-identical routines to dissect 
various strings.