lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev hyphenation (was tech. question: translating strings)


From: Vlad Harchev
Subject: Re: lynx-dev hyphenation (was tech. question: translating strings)
Date: Wed, 8 Sep 1999 08:13:30 +0500 (SAMST)

On Mon, 6 Sep 1999 address@hidden wrote:

> In message <address@hidden>, 
>            Vlad Harchev writes:
> > 
> >  As for 35 Mb of VSS - colorstyle changes takes 1Kb for each HTLine. There
> > were 22000 lines in that file - so that's why so big memory usage. I want it
> > to be fixed.
> 
> "You have the source."
> 
> I'll look into it, since it's my fault in the first place.

 Currenly, HTStyleChange is defined in following way.

typedef struct _stylechange {
        int     horizpos;       /* horizontal position of this change */
        int     style;          /* which style to change to */
        int     direction;      /* on or off */
        int     previous;       /* previous style */
} HTStyleChange;

It takes 16 bytes on x86. IMO nothing will be hurted if it was defined as:

typedef struct _stylechange {
        unsigned int direction:2;
        unsigned int horizpos:(sizeof(short)*CHAR_BITS -2);    /* horizontal
position of this change */
        unsigned short style;
} HTStyleChange;

It will take 4 bytes on x86. If this is bit-fields are non-portable (or the
size of the bitfield as constant expression is non-portable), then this should
be defined as #ifdef __GCC__ etc.

Also I'd like to use memory chunks (a big pool of memory dedicated to
allocating HTStyleChange in it. When no space in pool is left, another pool is
allocated with malloc). So HTLine.stylechanges will be a pointer pointing
inside that pool (when the line was assembled in split_line), rather than
array of MAX_LINE HTStyleChange's.

 It seems that the average line contains 6 colorstyle changes. So,
if such approach was used, the stylechanges would take 
(6*4*22000 = 528 000) - compare to 22 000 000.

 Not using memory pools will just reduce the 22M to 22/4 = 5 500 000 (but this
is IMO still not very good).

> -- 
> rob partington % address@hidden % http://lynx.browser.org/
> 

 Best regards,
  -Vlad


reply via email to

[Prev in Thread] Current Thread [Next in Thread]