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