bug#20887: 'make bootstrap' now verrrry slow due to recent isearch changes

[Artur Malabarba <bruce.connor.am@gmail.com>]

I think I see now. Reading the code for `get-char-code-property' shows
that I had to call a function stored in the extra slot.
Calling that function on the table seems to be sufficient to populate it.

2015-06-25 0:17 GMT+01:00 Artur Malabarba <bruce.connor.am@gmail.com>:
> 2015-06-24 21:05 GMT+01:00 Artur Malabarba <bruce.connor.am@gmail.com>:
>>> Why only the second?  All you care about is decomposition, that is,
>>> you need only loop over characters that have a non-nil value in the
>>> decomposition property.  You will see in characters.el how you can use
>>> map-char-table over a char-table loaded from uni-decomposition.el
>>> (similar to what we do there with uni-bidi et.).  Won't that be much
>>> faster?
>>>
>>> (I didn't actually try that, so perhaps I'm talking nonsense.)
>>
>> You're perfectly correct. I wasn't aware there's a char table for the
>> decomposition property (or any of the char properties for that
>> matter). Thanks, I'll add it in.
>
> Actually, I spoke (and pushed) too soon. I have no idea how this works
> The following code
>
> (map-char-table
>        (lambda (idx dec) (message "%S %S" idx dec))
>        (unicode-property-table-internal 'decomposition))
>
> calls the function a measly total of 100 times. The idx values are
> things like below (which I understand), but the dec values are HUGE
> strings (too big to post here, most of their content is the ^@ char)
> which make no sense to me. Am I using this wrong?
> (128 . 255)
> (256 . 383)
> (384 . 511)
> (512 . 639)
> (640 . 767)
> (768 . 895)
> (896 . 1023)
> (1024 . 1151)
> (1152 . 1279)