Ethereal-dev: SV: [Ethereal-dev] packet-parlay.c takes a very long time to compilein Fedora Co

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: "Anders Broman" <a.broman@xxxxxxxxx>
Date: Fri, 21 Apr 2006 20:15:22 +0200
Hi,
The dissector could probably be broken into smaller parts:
http://www.parlay.org/en/specifications/
Part   1: Common
Part   2: Third Party Call
Part   3: Call Notification
Part   4: Short Messaging
Part   5: Multimedia Messaging
Part   6: Payment
Part   7: Account Management
Part   8: Terminal Status
Part   9: Terminal Location
Part 10: Call Handling
Part 11: Audio Call
Part 12: Multimedia Conference
Part 13: Address List Management
Part 14: Presence

If needed.
Brg
Anders
-----Ursprungligt meddelande-----
Från: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] För Guy Harris
Skickat: den 21 april 2006 18:25
Till: Ethereal development
Ämne: Re: [Ethereal-dev] packet-parlay.c takes a very long time to compilein
Fedora Core 5

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.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev