[SHR] illume predictive keyboard is too slow

Olof Sjobergh olofsj at gmail.com
Fri Jan 30 21:16:57 CET 2009


On Fri, Jan 30, 2009 at 8:12 PM, The Rasterman Carsten Haitzler
<raster at rasterman.com> wrote:
> On Fri, 30 Jan 2009 08:31:43 +0100 Olof Sjobergh <olofsj at gmail.com> said:
>> But I think a dictionary format in plain utf8 that includes the
>> normalised words as well as any candidates to display would be the
>> best way. Then the dictionary itself could choose which characters to
>> normalise and which to leave as is. So for Swedish, you can leave å, ä
>> and ö as they are but normalise é, à etc. Searching would be as simple
>> as in your original implementation (no need to convert from multibyte
>> format).
>
> the problem is - the dict in utf8 means searching is slow as you do it in utf8
> space. the dict is mmaped() to save ram - if it wasnt it'd need to be allocated
> in non-swappable ram (its a phone - it has no swap) and thus a few mb of your
> ram goes into the kbd dict at all times. by using mmap you leave it to the
> kernels paging system to figure it out.
>
> so as such a dict change will mean a non-ascii format in future for this
> reason. but there will then need to be a tool to generate such a file.

Searching in utf8 doesn't mean it has to be slow. Simple strcmp works
fine on multibyte utf8 strings as well, and should be as fast as the
dictionary was before adding multibyte to widechars conversions. But
if you have some other idea in mind, please don't let me disturb. =)

Best regards,

Olof Sjöbergh




More information about the community mailing list