vintagedave on Kill dwm.exe on Windows for less input lag and better performance

Comment on Kill dwm.exe on Windows for less input lag and better performance

It’s lovely to see a short, simple WinAPI program written in C — often these days they use other frameworks. It’s old-school and bare metal.

The source was simple enough: get debug privileges, kill and suspend some processes, resume and if still missing restart, but I was puzzled at this function:

  DWORD64 GetLPSTRHash(LPSTR s){
      //more efficient string comparison
      DWORD64 h=0;
      BYTE c;
      while((c=*s++)) h=(h<<5)+h+c;
      return h;
  }

This is used while iterating the list of running processes for string comparison. I wonder if others on HN can share any light, please?

a) Why is an optimized string compare needed here? Even iterating a few hundred processes I would not have thought a simple (and likely already optimized) strcmp would be a hotspot

b) Why does this work as a good hashing function? It seems very simple: to the existing value, add a bitshift of the existing value plus the character. Googling shows some people referring to it as the Wang hash, in the context of pseudorandom numbers on GPUs. The actual content I can find on Wang’s hashing shows much larger (and to me more expected) algorithms, eg http://burtleburtle.net/bob/hash/integer.html

orlp 3y

I can't answer why the developer thought a faster hash was necessary. As to its quality as a hash function...

It's pretty poor, and slow on modern systems. It's known as the djb2 hash. (h << 5) + h is a way of writing 33*h without needing multipliers.

It fails pretty much every modern statistical test you can throw at it: https://gitlab.com/fwojcik/smhasher3/-/blob/main/results/per...

It's redeeming quality is that the code size is absolutely tiny, and that 33*h mod 2^64 is a reversible map, so if your input data is randomly distributed at least your output will be as well.

vintagedave 3y

Thanks! Yeah, not being good was my expectation but I thought, if it was there, it had to have a good reason. I appreciate the input and confirmation, thankyou :)

Random distribution of outputs does seem to minimise collisions on as a small an input set as a list of processes so I suppose the risk of killing the wrong process is minimal. I do think if I used the app I’d replace it though.

Comments