On Sat, Oct 19, 2013 at 12:43 PM, Alexander S. <alex0pla...@gmail.com> wrote: > Why removing mappedkeys? Sure, there may be no visible regression, but > checking every keypress against key bindings seems unreasonable to me.
On Sun, Oct 20, 2013 at 9:11 AM, Roberto E. Vargas Caballero
<k...@shike2.com> wrote:
> I don't like the actual solution of this problem, but we
> need some way of avoiding check all the keys.
My thought process was that it seemed strange to search one table
before searching another table, as it unnecessarily complicates the
code and the config. I assumed mappedkeys[] exists only for
performance reasons, and so I had first thought to replace mappedkeys
with a sorted key[] table so that searches can be aborted early. When
I found that I could not detect any performance difference between
searching a sorted key[] and an unsorted key[], I decided to remove
the sorting as well.
I've attached this version of the patch for reference. It's maybe a
bit nice that sorting also removes the need to be careful about the
order of key definitions in config.h with respect to XK_ANY_MOD. It's
also less code than the existing mappedkeys[] code.
However, since (I'm assuming) the only point of mappedkeys[] or
sorting key[] is for performance, and since there is no measurable
performance difference among these three versions, I think the
simplest code should win. Of course, it's possible that on someone's
system there is a noticeable performance difference, but this would be
surprising to me. On my system, making one million calls to kmap() and
checking all key[] entries on each call takes 0.7s. I don't know
anyone who can type that fast. :)
-Mark
0001-Replace-mappedkeys-with-sorting-on-key.patch
Description: Binary data
