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