On Tue, Mar 03, 2009 at 01:12:36PM +0100, Dennis Benzinger wrote: > > Hi Markus! > > Am 03.03.2009 11:14, Markus Heidelberg schrieb: > > Dennis Benzinger, 03.03.2009: > >> > >> Hi! > >> > >> Am 03.03.2009 06:40, James Vega schrieb: > >> > [...] > >> >> 2) Vim compiled with the --disable-multibyte configure option cannot > >> >> use > >> >> UTF-8, or any other multibyte encoding; in fact it doesn't even accept > >> >> the 'encoding' option as valid. > >> > > >> > Is there a reason to allow building Vim without multibyte support? > >> > Always having multibyte support would make the code simpler/smaller. > >> > >> It would make the code smaller but compiling without multibyte support > >> probably makes the resulting binary smaller. That can make a big > >> difference for users on resource constrained systems. > > > > What do you mean exactly with "resource constrained systems"? > > On an old PC, Vim with multibyte should still run fast. > > [...] > > I meant systems which have or can use only a small amount of memory. For > example (16bit) MS-DOS where you can only use 640KB. These systems may > be rare nowadays but if you'll encounter one you'd probably be happy to > be able to minimize the size of the binary.
Indeed, but there are currently checks that prevent Vim from building with multibyte support on such systems (ints that are smaller than 32 bit). I guess supporting such OSes would be a reason not to disallow building without multibyte entirely. That does raise the question of where the trade-off between keeping legacy, mostly unused code versus dropping support occurs. > But I didn't try it out how > much the size differs between a multibyte and a non-multibyte build. > Therefore I wrote "_probably_ makes the resulting binary smaller" ;-) > > So if ripping out non-multibyte support does not make the code much > simpler or smaller I'd simply keep it. Do you have any idea much simpler > or smaller the code would be? Well, since supporting 16bit systems is still desirable, there'd be no change in code size. Just for the sake of argument, though, it would remove 933 '#ifdef FEAT_MBYTE' (or equivalent) conditional parts of the code and 4 '#ifndef FEAT_MBYTE' (or equivalent). How many of the #ifdef scenarios have a paired #else would require more investigation than I'm willing to do for the sake of argument. :) As for the resulting binary sizes: features=tiny, with multibyte: 560.9k features=tiny, w/out multibyte: 493.4k 67k or 12% saving features=small, with multibyte: 618.7k features=small, w/out multibyte: 551.1k 67k or 11% saving features=normal, with multibyte: 1390.3k features=normal, w/out multibyte: 1279.0k 111k or 8% saving -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <james...@jamessan.com>
signature.asc
Description: Digital signature
