On Oct 16, 2017, at 3:05 AM, Graham Bloice wrote:
> On 13 October 2017 at 21:50, Gerald Combs wrote:
>
>> Before we migrated away from NMake, epan/Makefile.nmake built the assembly
>> versions of various routines for x86 (but not x64) defined in
>> epan/asm_utils_win32_x86.asm. Should we resu
On Mon, Oct 16, 2017 at 7:09 AM, Richard Sharpe
wrote:
> On Sun, Oct 15, 2017 at 7:36 PM, Michael Mann via Wireshark-dev
> wrote:
>>
>>
>>
>> -Original Message-
>> From: Richard Sharpe
>> To: Developer support list for Wireshark
>> Sent: Sat, Oct 14, 2017 1:47 pm
>> Subject: [Wireshark-
On Sun, Oct 15, 2017 at 7:36 PM, Michael Mann via Wireshark-dev
wrote:
>
>
>
> -Original Message-
> From: Richard Sharpe
> To: Developer support list for Wireshark
> Sent: Sat, Oct 14, 2017 1:47 pm
> Subject: [Wireshark-dev] Reusing the code for various things in ieee802.11
> in other di
Hi Paul,
If you are working in Windows environment you can use
QueryPerformanceCounter (QPC) to get a high resolution time value. The
actual time resolution might vary, use QueryPerfomanceFrequency to get
the resolution. At my Windows 10 system I get a frequency of 3914059,
i.e. ~250ns.
But there
Visual Studio
On 14 October 2017 at 15:18, Paul Offord wrote:
> I’m investigating a performance problem with the TRANSUM dissector. I’d
> like to measure the accumulated time taken to execute a function in a
> Release build. My basic idea is to do something like this:
>
>
>
> guint32 execute_t
On 13 October 2017 at 21:50, Gerald Combs wrote:
> Before we migrated away from NMake, epan/Makefile.nmake built the assembly
> versions of various routines for x86 (but not x64) defined in
> epan/asm_utils_win32_x86.asm. Should we resurrect it in epan/CMakeLists.txt
> or get rid of it along with
On Oct 14, 2017, at 7:18 AM, Paul Offord wrote:
> I’m investigating a performance problem with the TRANSUM dissector. I’d like
> to measure the accumulated time taken to execute a function in a Release
> build. My basic idea is to do something like this:
...
> Is there a standard wa
On Oct 15, 2017, at 11:54 PM, Roland Knall wrote:
> Please keep in mind, that those are not very precise. High-resolution timer
> measurements cannot be done in a precise fashion on most windows systems for
> ethernet applications.
This isn't necessarily an Ethernet application; the tests he's
On Oct 15, 2017, at 1:32 PM, Peter Wu wrote:
> Not sure about the Status line question, but you can measure elapsed
> microseconds with something like:
>
>guint64 start_time, end_time;
>
>start_time = g_get_monotonic_time();
>// ...
>end_time = g_get_monotonic_time();
>// ..
Hi Paul,
Can you reproduce the slow behavior with tshark? If so, then it might be worth
to run profiling tools against it with less noise from the GUI. For Linux you
could use "perf" for example:
perf record -g dwarf tshark -r your.pcap
perf report
Add -D1000 to the perf record command
10 matches
Mail list logo
