manual/aspell.html/Notes-on-8_002dbit-Characters.html

   1 <html lang="en">
   2 <head>
   3 <title>Notes on 8-bit Characters - GNU Aspell 0.60.6.1</title>
   4 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   5 <meta name="description" content="Aspell 0.60.6.1 spell checker user's manual.">
   6 <meta name="generator" content="makeinfo 4.8">
   7 <link title="Top" rel="start" href="index.html#Top">
   8 <link rel="up" href="Implementation-Notes.html#Implementation-Notes" title="Implementation Notes">
   9 <link rel="prev" href="Aspell-Suggestion-Strategy.html#Aspell-Suggestion-Strategy" title="Aspell Suggestion Strategy">
  10 <link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
  11 <!--
  12 This is the user's manual for Aspell
  13
  14 GNU Aspell is a spell checker designed to eventually replace Ispell.
  15 It can either be used as a library or as an independent spell checker.
  16
  17 Copyright (C) 2000--2011 Kevin Atkinson.
  18
  19      Permission is granted to copy, distribute and/or modify this
  20      document under the terms of the GNU Free Documentation License,
  21      Version 1.1 or any later version published by the Free Software
  22      Foundation; with no Invariant Sections, no Front-Cover Texts and
  23      no Back-Cover Texts.  A copy of the license is included in the
  24      section entitled "GNU Free Documentation License".
  25    -->
  26 <meta http-equiv="Content-Style-Type" content="text/css">
  27 <style type="text/css"><!--
  28   pre.display { font-family:inherit }
  29   pre.format  { font-family:inherit }
  30   pre.smalldisplay { font-family:inherit; font-size:smaller }
  31   pre.smallformat  { font-family:inherit; font-size:smaller }
  32   pre.smallexample { font-size:smaller }
  33   pre.smalllisp    { font-size:smaller }
  34   span.sc    { font-variant:small-caps }
  35   span.roman { font-family:serif; font-weight:normal; }
  36   span.sansserif { font-family:sans-serif; font-weight:normal; }
  37 --></style>
  38 </head>
  39 <body>
  40 <div class="node">
  41 <p>
  42 <a name="Notes-on-8-bit-Characters"></a>
  43 <a name="Notes-on-8_002dbit-Characters"></a>
  44 Previous:&nbsp;<a rel="previous" accesskey="p" href="Aspell-Suggestion-Strategy.html#Aspell-Suggestion-Strategy">Aspell Suggestion Strategy</a>,
  45 Up:&nbsp;<a rel="up" accesskey="u" href="Implementation-Notes.html#Implementation-Notes">Implementation Notes</a>
  46 <hr>
  47 </div>
  48
  49 <h3 class="appendixsec">A.2 Notes on 8-bit Characters</h3>
  50
  51 <p>There is a very good reason I use 8-bit characters in Aspell. Speed
  52 and simplicity. While many parts of my code can fairly easily be
  53 converted to some sort of wide character as my code is clean. Other
  54 parts cannot be.
  55
  56    <p>One of the reasons why is because in many, many places I use a direct
  57 lookup to find out various information about characters. With 8-bit
  58 characters this is very feasible because there is only 256 of
  59 them. With 16-bit wide characters this will waste a LOT of space. With
  60 32-bit characters this is just plain impossible. Converting the lookup
  61 tables to another form is certainly possible but degrades performance
  62 significantly.
  63
  64    <p>Furthermore, some of my algorithms rely on words consisting only on a
  65 small number of distinct characters (often around 30 when case and
  66 accents are not considered). When the possible character can consist
  67 of any Unicode character this number becomes several thousand, if
  68 that. In order for these algorithms to still be used, some sort of
  69 limit will need to be placed on the possible characters the word can
  70 contain. If I impose that limit, I might as well use some sort of
  71 8-bit characters set which will automatically place the limit on what
  72 the characters can be.
  73
  74    <p>There is also the issue of how I should store the word lists in
  75 memory? As a string of 32 bit wide characters. Now that is using up 4
  76 times more memory than characters would and for languages that can fit
  77 within an 8-bit character that is, in my view, a gross waste of
  78 memory. So maybe I should store them is some variable width format
  79 such as UTF-8. Unfortunately, way, way too many of the algorithms will
  80 simply not work with variable width characters without significant
  81 modification which will very likely degrade performance. So the
  82 solution is to work with the characters as 32-bit wide characters and
  83 then convert it to a shorter representation when storing them in the
  84 lookup tables. Now that can lead to an inefficiency. I could also use
  85 16 bit wide characters, however that may not be good enough to hold all
  86 future versions of Unicode and therefore has the same problems.
  87
  88    <p>As a response to the space waste used by storing word lists in some
  89 sort of wide format some one asked:
  90
  91    <blockquote>
  92 Since hard drives are cheaper and cheaper, you could store a dictionary
  93 in a usable (uncompressed) form and use it directly with memory
  94 mapping. Then the efficiency would directly depend on the disk caching
  95 method, and only the used part of the dictionaries would really be
  96 loaded into memory. You would no more have to load plain dictionaries
  97 into main memory, you'll just want to compute some indexes (or
  98 something like that) after mapping.
  99 </blockquote>
 100
 101    <p>However, the fact of the matter is that most of the dictionary will be
 102 read into memory anyway if it is available. If it is not available
 103 then there would be a good deal of disk swaps. Making characters
 104 32-bit wide will increase the chance that there are more disk swaps.
 105 So the bottom line is that it is more efficient to convert characters
 106 from something like UTF-8 into some sort of 8-bit character. I could
 107 also use some sort of disk space lookup table such as the Berkeley
 108 Database. However this will <strong>definitely</strong> degrade performance.
 109
 110    <p>The bottom line is that keeping Aspell 8-bit internally is a very well
 111 though out decision that is not likely to change any time soon. Feel
 112 free to challenge me on it, but, don't expect me to change my mind
 113 unless you can bring up some point that I have not thought of before
 114 and quite possibly a patch to solve cleanly convert Aspell to Unicode
 115 internally without a serious performance lost OR serious memory usage
 116 increase.
 117
 118    </body></html>
 119