On Oct 16, 2017, at 3:05 AM, Graham Bloice <graham.bloice@xxxxxxxxxxxxx> wrote:
> On 13 October 2017 at 21:50, Gerald Combs <gerald@xxxxxxxxxxxxx> 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 the NASM download in tools/win-setup.ps1?
>
> I was vaguely under the impression that compiler intrinsics were the way forward for these kind of things
Compiler intrinsics are the way to do things for which there are compiler intrinsics. Unless by "compiler intrinsics" you're referring to "inline asms" of the sort that GCC provides, I'm not sure there are compiler intrinsics for most of the operations for which we're providing assembler-language implementations. (The one exception is strcmp() and the like, which GCC, and possibly other compilers, often turn into inline code, and for which there are often optimized implementations, at least on some platforms, because it's part of C.)
> However, I don't see much point in attempting to optimise things without measuring what we're trying to optimise, i.e. we need some form of benchmark.
Tomas did some profiling back in
https://www.wireshark.org/lists/wireshark-dev/200711/msg00303.html
and in
https://www.wireshark.org/lists/wireshark-dev/200711/msg00068.html
said
I was able (with about 80 lines in assembler) to reduce time spent in libwireshark.dll during startup from cca 2600ms to 1300ms on my PC.
so that removed about 1.3 seconds of startup time.
