Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.postscript > #3750
| From | Carlos <carlos@cvkm.cz> |
|---|---|
| Newsgroups | comp.lang.postscript |
| Subject | Re: Speed or space |
| Date | 2022-02-10 15:28 +0100 |
| Message-ID | <20220210152810.00002cff@cvkm.cz> (permalink) |
| References | <62027f03$1@news.ausics.net> |
On Wed, 9 Feb 2022 01:32:35 +1100 David Newall <davidn@davidnewall.com> wrote: > Still working on utf8show and have classic space vs. time tradeoff. > > I can store the UnicodeEncoding map in a Dictionary, which is > blindingly fast, or in a sparse array, which is more compact but > slower to access. Every glyph painted needs a lookup in the map. I don't know what a sparse array is in this context. Is it like the input array to unicodefont? In that case maybe it could be optimized, by, idk, putting code points in entries 0, 2, 4, 6, ... to speed up lookup, and the corresponding arrays with glyph names (or just the main glyph name) in entries 1, 3, 5, 7, ..., or something like that. > > ---Bytes Used-- --Savings-- -Time(ms)-- S:D ms > Map Source Dict Sparse Bytes % Dict Sparse Ratio > AdobeGlyphList(1) 222472 180798 41686 19% 161 2968 18.45 > FreeSerif.gn2(2) 442320 356006 86314 20% 604 2856 4.73 > UnifontMedium.gn2(3) 3357832 2173806 1184026 35% 156 949 6.08 > > (1) AdobeGlyphList from ghostscript v9.50 on Ubuntu 20.04.3. > > (2) Generated by fontforge from FreeSerif.sfd extracted from > freefont-src-20120503.tar.gz from ftp.gnu.org/gnu/freefont. > > (3) Generated by fontforge from unifont-14.0.01.ttf extracted > from unifont-14.0.01.tar.gz from ftp.gnu.org/gnu/unifont/. > > Tests were performed using Ghostscript 9.5 on Ubuntu 20.04.3 with > Intel(R) Core(TM) i7-1165G7 @ 2.80GHz. Glyphs for UNICODE values 0 > through 150,000 were retrieved from each map five times. > > I don't know why accessing the sparse Adobe map is so much slower than > the other two. Average retrieval time is under 4ns; for UnifontMedium > it's under 1.3ns. > > I'm going to implement it one way only. Which should it be? Contrary to John's opinion, I don't think space matters much, especially if it's only 3 MB. So I'd choose speed. But then, I don't know anything about Postscript printers or other low capacity devices. C.
Back to comp.lang.postscript | Previous | Next — Previous in thread | Next in thread | Find similar
Speed or space David Newall <davidn@davidnewall.com> - 2022-02-09 01:32 +1100
Re: Speed or space John Reiser <vendor@BitWagon.com> - 2022-02-09 09:59 -0800
Re: Speed or space Carlos <carlos@cvkm.cz> - 2022-02-10 15:28 +0100
Re: Speed or space David Newall <davidn@davidnewall.com> - 2022-02-16 14:29 +1100
csiph-web