<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 4, 2015 at 9:35 AM, Behdad Esfahbod <span dir="ltr"><<a href="mailto:behdad@behdad.org" target="_blank">behdad@behdad.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15-03-03 04:08 PM, Behdad Esfahbod wrote:<br>
> On 15-03-03 03:56 PM, Raimund Steger wrote:<br>
>> > On 02/27/15 07:57, Akira TAGOH wrote:<br>
>>> >> [...]<br>
>>> >> diff --git a/fc-blanks/fc-blanks.py b/fc-blanks/fc-blanks.py<br>
>>> >> [...]<br>
>>> >> +fp =<br>
>>> >> urllib2.urlopen('<a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%3AGC%3DZs%3A][%3ADI%3A]&abb=on&ucd=on&esc=on&g" target="_blank">http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[%3AGC%3DZs%3A][%3ADI%3A]&abb=on&ucd=on&esc=on&g</a>')<br>
>>> >><br>
>> ><br>
>> > 4191 codepoints?<br>
>> ><br>
>> > Before it was more like 60...<br>
> Most of the new ones are blocks of unassigned codepoints.<br>
><br>
>> > 'fc-cache -f' now spends 100x more time in FcBlanksIsMember, which makes for<br>
>> > several seconds difference on some of my boxes. In the profiler:<br>
> Yeah, because currently it's stored as a list of codepoints, which is very<br>
> inefficient.  Worse, FcBlanksIsMember does a linear search...<br>
><br>
> I'm personally in support of killing configurable blanks completely.  This is<br>
> very close to that.  Let me improve the storage and implement bsearch...<br>
<br>
</span>As fun as doing this is, I have to focus on other things.<br>
<br>
Akira, mind implementing this?  Probably the simplest data structure would be<br>
to store ranges.<br></blockquote><div><br></div><div>Sure. will work on that.</div><div><br></div></div>-- <br><div class="gmail_signature">Akira TAGOH</div>
</div></div>