GNU bug report logs - #47711
27.1; Deferred highlighting support in `completion-all-completions', `vertico--all-completions`

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, monnier <at> iro.umontreal.ca, 48841 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org, 47711 <at> debbugs.gnu.org
Subject: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting
Date: Mon, 16 Aug 2021 19:25:00 +0100

Dmitry Gutov <dgutov <at> yandex.ru> writes:

>> prepared a version of my patch that is based on weak-keyed hash tables.
>> Slightly slower, but not much. Here are the usual benchmarks:
>
> Cool, I'll take a look, thanks.

I've made it faster, now very close to the string-propertizing approach,
itself very close to the theoretical best (which is no copy, no
highlight).  See the tip of the
scratch/icomplete-lazy-highlight-no-string-props branch, which I had to
rewrite (some Git flub-up).  All benchmarks after sig.

João

(require 'cl-lib)

;; Introduce 300 000 new symbols to slow things down.  Probably more
;; than most non-Spacemancs people will have :-)

;; (setq ido-enable-flex-matching t)
;; (ido-mode)
;; (ignore-errors (ido-ubiquitous-mode))
;; (fido-mode)
;; (fido-vertical-mode)
;; (vertico-mode)

;; (hash-table-keys completion--get-lazy-highlight-cache)

(defmacro heyhey ()
  `(progn
     ,@(cl-loop repeat 300000
	       collect `(defun ,(intern (symbol-name (gensym "heyhey"))) () 42))))
;; (setq completion-styles '(substring))
(setq completion-styles '(flex))
(heyhey)
(setq icomplete-show-matches-on-no-input t)

(symbol-name 'mouse-kill)

(when nil
  ;; Press C-u C-x C-e C-m quickly to produce a sample. Always discard
  ;; the first sample in the session, it tends to have an extra GC and be
  ;; slower.
  (benchmark-run (completing-read "" obarray))

  ;; don't use string props
  (2.848873438 6 0.8307729419999994)
  (2.848416202 6 0.8370667889999996)
  (2.786944063 6 0.8230433460000004)
  (2.7815761840000004 6 0.819654023)
  (2.6929080819999998 5 0.7036257240000001)

  ;; string props
  (2.630354852 4 0.7071441910000011)
  (2.594761891 4 0.7082679669999994)
  (2.589480755 4 0.7112978109999997)
  (2.661196709 4 0.7130021060000011)
  (2.844372962 4 0.7378870879999999)

  ;; master
  (3.6339847759999997 12 1.601142523)
  (3.757091055 12 1.6231055449999996)
  (3.785980977 12 1.6333413839999995)
  (3.716144927 12 1.6100998260000008)
  (3.808275042 11 1.611891043)


  ;; these next two are not comparable to the above, because in
  ;; ab23fa4eb22f6557414724769958a63f1c59b49a I added sorting to flex
  ;; which changes results, and Daniel's patch no longer applies
  ;; cleanly.

  ;; daniel's patch
  (3.420418068 10 1.451012855)
  (3.603226896 10 1.672325507)
  (3.501318685 10 1.6150095739999992)
  (3.659821971 10 1.6580361760000004)
  (3.624743674 10 1.657498823)


  ;; master just before daniel's patch (254dc6ab4c)
  (2.611424665 10 1.5267066549999981)
  (2.48811409 10 1.486639387000002)
  (2.472587389 10 1.479865191)
  (2.543277273 10 1.510667634999999)
  (2.546243312 10 1.4986345790000009)
  
  )

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.