Comment # 10
on bug 10329
from Anders Broman
(In reply to Evan Huus from comment #9)
> > *not* short-circuit if they're different (which should be rare).
>
> Does the capture you're profiling hit this case a lot then? I thought it
> should almost never happen, so I'd be very surprised if you're seeing it so
> much to cause this much slowdown.
I'm not sure what "this case" is but for sure the patch causes a huge
difference in the valgringd score. The trace is "normal" traffic on an IMS
network from one of our labs e.g SIP, DIAMETER, H248, ISUP etc transported on
TCP UDP and SCTP mixed in with VLAN and routing protocols. In my opinion a
normal protocol mix.
>
> > Probably because the OPCUA code has been changed not to use proto_tree_add text().
>
> A simple change to _add_item() wouldn't make a difference, they both use the
> same TRY_TO_FAKE_THIS_ITEM logic.
This was a mistake on my end i expanded the macro att .._proto_item_new in
order to do debugging and only changed it back there...
>
> > Could this type of problem be fixed in proto_item_set_end() instead?
>
> No, there are a number of functions that depend on this behaviour being
> correct, it would be fragile to try and fix them all - I believe my original
> analysis/solution is correct, though there may be a case (ds_tvb == NULL?)
> in which we can safely short-circuit which I missed in my original analysis.
Ok lets put it this way then, could we fix the original problem in a way causin
less degradation of the valgrind score? Now we have 50% increase.
I thik Jacub put up a public file for profiling, perhaps that could be used to
try to find out what's going on.
I'm out of office next week so I'm not able to look into it further for another
week.
You are receiving this mail because:
- You are watching all bug changes.