- standard Emacs 24.3 indeed provides significant speed improvement over 23.3 in ido flexible matching - original ido-better-flex performance is terrible - speed-hack introduces two improvements: ido-mode patches and (shared) bitmaps
- ido-mode patches improve ido E24 performance - bitmap optimization provides significant improvement for better-flex but slows down E24 a little bit - shared bitmaps significantly improve performance of all methods
My setup:
- debian x64 testing on Lenovo R400 (Intel Core2 Duo) - debian testnig emacs 23.3 & emacs-snapshot 20121115 from http://emacs.naquadah.org/ - to avoid cpu frequency scaling, I call
cpufreq-set -r -g userspace -d 800MHz -u 800MHz - I use benchmark-run to meassure time and garbage collection
Tests
I simulate interactive ido mode by calls to ido-set-matches. I emulate typing by
setting ido-text. I start with one character and append one character for each
iteration (eg. 'a', 'ab', 'abc' etc...)
I use 4 different tests:
- "abcdefghijklmnopqrstuvwxyz" - this test favours my patches, because they reuse results from last matching.
- "-etaimn" - most common characters in English (and Emacs commands). The number
of completions will not be reduced too much in this test.
- "bcfile" - "real-world" example. Shortcut for byte-compile-file
- "fndgd" - second "real-world" example. Shortcut for find-grep-dired
Ido uses obarray to complete all 4 examples. To have same conditions, I saved the completion list to file (39580 symbols). All tests
start with fresh Emacs and with the same list to complete.
Variants
I tested following variants:
- ido-mode - ido mode file version - cmn - ido-set-common-completion is part of the test - flx - ido-enable-flex-matching on and off
- cas - ido-case-fold on and off - rgx - ido-enable-regexp on and off
- better - ido-better-flex off, original and patched version - cache - use of bimaps cache (only for ido-speed-hack)
ido-mode variants:
- 23.3 - file from 23.3 distribution - 24.3 - file from debian emacs-snapshot package (as of 20121122) - patched - 24.3 + patches (function inlining and avoid gc) - bitmaps - using ido-speed-hack bitmaps and result caching
- shared - bitmaps are cached between executions.
On Thu, Nov 22, 2012 at 10:36 AM, Daniel Skarda <address@hidden> wrote:
> > Hi Dmitry, > > thanks for the suggestions. I will prepare some benchmarks using new Emacs and send the results. > I already did some statistics with elp during development, but I suspect that the numbers are not precise.
> > I am curious which improvements will be the fastest :) > > Regards, > Dan > > > On Wed, Nov 21, 2012 at 4:37 AM, Dmitry Gutov <address@hidden> wrote:
>> >> Daniel Skarda <address@hidden> writes: >> >> Hey Daniel, >> >> Like Leo said, please provide some numbers.
>> >> A comparison to the current trunk would be best, since it contains an >> additional optimization compared to the emacs-24 branch. >> >> Here my test setup from the relevant discussion:
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12796#47 >> >> --Dmitry >> >> > I like to use ido mode for everything, including very large lists (like M-x or
>> > info). Unfortunately ido is not suitable for such lists. On my old notebook, >> > performance is not amazing, so I took the challenge and spend some time with >> > profiler. >> >
>> > I improved the performance in several steps: >> > >> > - inlined several functions >> > - disabled ido-case-fold for some completions (eg commands) >> > - prunning collections based on character bitmaps
>> > - caching character bitmaps during completion or for same completions >> > - caching intermediate completion lists when adding new characters >> > >> > You can view my changes on github:
>> > >> > - https://github.com/orfelyus/ido-speed-hack >> > - https://github.com/orfelyus/ido-mode-el
>> > >> > - (and optionally) https://github.com/orfelyus/ido-better-flex >> > >> > ido-speed-hack includes large changes (bitmaps) while ido-mode-el includes minor
>> > changes to ido.el >> > >> > The changes made huge speed improvements on my notebook and ido does not feel >> > sluggish even with very large lists. >> > >> > Could you please test my improvements? I would appreciate any feedback.
>> > Dan >> > >> > ps: I am not subscribed to the mailing list, please keep me in Cc > >