[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OKURI-NASI
From: |
Lars Ingebrigtsen |
Subject: |
Re: OKURI-NASI |
Date: |
Mon, 30 May 2022 15:19:23 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Doing some very light profiling here, a lot of the time is taken up by
>> skkdic-get-entry, which is just lookup-nested-alist.
>
> Odd: `skkdic-get-entry` didn't even appear in the profile I got (and
> `lookup-nested-alist` was dwarfed by other things):
It's a defsubst -- I was profiling uncompiled code:
6278 48% - skkdic-breakup-string
6262 48% - let
6258 48% - or
6242 48% - and
5871 45% - let
5763 44% - while
5735 44% - let
3995 30% + skkdic-get-entry
>> My guess is that if somebody took a look ja-dic-cnv.el, this algorithm
>> could be made substantially more efficient by using other data
>> structures than an extremely long nested alist.
>
> I believe those (nested) alists shouldn't be that long (IIUC it's
> a trie-like data-structure, a bit like keymaps, so even with many
> entries in total, the total depth of the tree should be fairly short and
> the length of each list (i.e. the out degree of each node) shouldn't be
> very large either).
Hm, right...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
- Re: OKURI-NASI, (continued)
- Re: OKURI-NASI, Lars Ingebrigtsen, 2022/05/29
- Re: OKURI-NASI, Eli Zaretskii, 2022/05/29
- Re: OKURI-NASI, Lars Ingebrigtsen, 2022/05/30
- Re: OKURI-NASI, Eli Zaretskii, 2022/05/30
- Re: OKURI-NASI, Lars Ingebrigtsen, 2022/05/30
- Re: OKURI-NASI, Lars Ingebrigtsen, 2022/05/30
- Re: OKURI-NASI, Eli Zaretskii, 2022/05/30
Re: OKURI-NASI, Stefan Kangas, 2022/05/30