The load time for NFSv4 captures can be reduced by up to 2.5 times by skipping the 'proto_' routines during the initial load (first pass) of the capture in Wireshark. However, if '!tree' is used to detect if this is the first pass, 'Find's for text in the Info column fails because during a Find, 'tree' is temporarily set to NULL. If instead the !pinfo->fd->flags.visited' is used, Finds work well but tshark's io,stat fails to see the NFS-related field values unless the '-2' (two pass) option of tshark is specified. Is there a way to detect in dissect-nfs.c, via a global variable or by calling a routine, if tshark or Wireshark is being run? If so, is it also possible to detect if tshark's '-2' option was specified? This question is marked "community wiki". asked 29 Mar '13, 16:02  commsguy edited 29 Mar '13, 16:04 |
One Answer:
No.
Which you don't want to do if:
etc.. The way you determine whether to construct a protocol tree is, err, umm, by looking at the
If And (Also, it's not a case of "temporarily" being set to NULL. It's set to a non-null value iff the protocol tree is needed; it's not as if "non-null" is the standard setting and "null" merely a temporary special setting.) answered 29 Mar '13, 17:41  Guy Harris ♦♦ edited 29 Mar '13, 19:44 |
Guy, Thanks. That answers my question. It is my understanding that that an 'if' operation (e.g., "if (tree) proto_tree_add_item(tree, hfindex, tvb, offset, 8, ENC_BIG_ENDIAN);") is less costly to performance than making the call to the 'proto_tree_' routine and having it return if tree is NULL because when the routine is called, its arguments have to be pushed and popped off the stack or copied to and read from registers.
In your opinion is it worthwhile to add an 'if (tree)' check to each proto_tree call or a set of such calls, or does the ugliness they cause outweigh the gains in performance afforded by them?
The
if (tree)takes more code (as the test is done at the call site rather than in the called routine), and the test is done in the called routine anyway, but it avoids the procedure call, so the net result may be positive. If you can bundle multiple calls under oneif, there's probably a greater performance improvement.It's worth doing it if it makes a big difference (and a 2.5x difference is big); it'd be nice to be able to avoid it, but that goes down the path of dynamic code generation (whether by interpretation of, for example, specialized bytecode, or by using something such as LLVM), which is a bigger project (worthwhile considering, but bigger).
Guy, I spent a great deal of time adding "if (tree)" clauses throughout the packet-nfs.c code and did as much bundling of proto_tree routines within those clauses as possible. To my surprise, there was only a 6% improvement in the load time. At least to me, it doesn't seem worth the time and effort.
I went over the NFS dissector once again and found that I had only covered about half the code with "if (tree)" checks. I paid special attention to the high volume routines. I completed the work and now I'm seeing a 21% reduction in load time. For me that makes it worth the effort because with the advent of 10Gig networks, captures are becoming much larger (e.g., 2 to 4 million frames).