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.