Yegappan wrote:
> > > On Wed, Jan 19, 2022 at 4:34 AM Bram Moolenaar ***@***.***> > > > wrote: > > > > > > > I'm not sure this is an improvement. Using a switch statement the > > > > compiler > > > > can find the optimal way to select the code to execute. A linear search > > > > through an array is likely to always be slower. > > > > A binary search would be much better, but it is hard to get the key > > > > codes > > > > in sorted order. > > > > A kind of hashtable might also work. It would have to be created at > > > > runtime though. > > > > > > > > We have a similar problem for the normal mode command, which is using a > > > > sorted index table. It is filled in init_normal_cmds(). > > > > This adds to the startup time. > > > > > > > > We could change this to generate the table at compile time. Then the > > > > table > > > > used for "g" commands could also use a binary search, like in > > > > find_command(). The "g" command table would have gaps in the lower block > > > > (the part where the typed character can directly be used as an index, > > > > up to > > > > "~"). Or not use a lower block. > > > > > > > > > > > > > > > I will rework the patch to use a binary search to lookup the function for > > > a > > > given key. > > > > We have "make cmdidxs" for the table of Ex commands. It's a different > > mechanism, but the way it is used can function as an example. The > > result is efficient at runtime. > > > > Perhaps we just need a script that can sort the array, so that a binary > > search is possible. Or generate the lookup table, so that > > init_normal_cmds() isn't needed. > > > > The create_cmdixds.vim is able to sort the Ex commands as the names are > all strings. But the nv_cmds[] array contains key codes (like Ctrl_A, > K_MOUSEUP, etc). So from an external script, it will be difficult to translate > these codes (which are C macros) to corresponding numbers which can > be sorted. > > We can make sure the g command table is sorted (at least upto the '~' > character), > so that the printable character can be used directly as the index and and do a > binary search for the special keycodes. I found some hints about performance, it most opinions are that using a switch statement, leaving the optimization to the compiler, is the best. For the first command character we can use the index directly for many keys, so that makes it fast. It also has many more entries. For the nv_g_cmd() function I think we can leave it a switch. We can move the larger code blocks to a function to keep overview. Especially "$", that is 64 lines. I would think if the code goes over ten lines it's worth moving to a function. -- There can't be a crisis today, my schedule is already full. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20220120111746.926B11C1905%40moolenaar.net.
