 | 1 | initial version |
I was hoping that's the kind of operation that could "pin" the CPU.
As a multiprocessor system, your iMac has 8 CPUs.
Packet dissection is a process that is hard to parallelize so that it can use more than one thread; the dissection of packet N is not necessarily independent of the dissection of packet M, for M < N.
It is not currently parallelized, so it only uses one CPU, and only one of your CPUs could be pinned by the process, so it may not get much above 12.5% of the system's total CPU power.
We've thought some about ways to try to parallelize it, e.g. assigning packets to CPUs based on transport-layer connections to reduce the chances that two packets being dissected in parallel will have dependencies that force dissection of the later packet to stall until dissection of the earlier packet completes, as well as adding dependency checking to stall in the case that there is a dependency between packets from different connections. Unfortunately, the process of identifying the connection to which a packet belongs is part of the dissection process, so this might involve handing packets from one thread to another.
As for memory, saving the full results of dissection if you have enough physical memory (and perhaps discarding it if the system is reporting memory pressure to the application; macOS has mechanisms to do that, other OSes might or might not) might speed up filtering, but so might reducing the amount of dissection done to evaluate a filter.
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
