Re: Boost process and C

Flash Gordon wrote:
jacob navia wrote:
Flash Gordon a écrit :
Is an extra byte (or word, or double word) for a flags field really
that big an overhead?

Well, I have that extra "Flags" field in the string library of
lcc-win32. I have the size as a size_t as you propose, and I need 32
bits for the flags.

The problem is that 32 bits is quite a lot for a few bits info... For
programs that use extensively strings, 32 bits multiplied by several
thousand small strings can make a big difference in RAM used, specially
for the more common short strings.

I see the point of Bstrlib, and it is a very valid design decision.

I've yet to see software where short strings made up a significant
portion of the memory footprint and saving the memory that avoiding the
flags would be of real use. Of course, such applications might exist.

Any program that reads words from any language dictionary. Like a
spell checker, or a word puzzle solver/creator, or a spam filter. For
dictionaries the size of the english language dictionary, these kinds
of applications can typically push the L2 cache of your CPU pretty
hard.

Personally I would say that using negative lengths was asking for
problems because at some point a negative length will be checked without
first changing it to positive.

I think you miss the point. If the string length is negative then it
is erroneous. That's the point of it. But the amount of memory
allocated being negative, I use to indicate that the memory is not
legally modifiable at the moment, and being 0 meaning that its not
modifiable ever. The point being that the library blocks erroneous
action due to intentionally or unintentionally having bad header values
in the same test. So it reduces overhead, while increasing safety and
functionality at the same time.

You know, you can actually read the explanation of all this in the
documentation if you care to do so.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.

Relevant Pages

  • Re: Internal Representation of Strings
    ... strings are likely to be very small, ... It just seems like low overhead strings always have a ... (No, I haven't built a compiler, yet). ... saving 1 or 2 bytes will not matter so much if the memory comes ...
    (comp.compilers)
  • Re: Boost process and C
    ... thousand small strings can make a big difference in RAM used, ... portion of the memory footprint and saving the memory that avoiding the ... flags would be of real use. ... the subset of it that is likely to be actually in use is probably an order of magnitude smaller and so could easily fit in with the extra overhead. ...
    (comp.lang.c)
  • Re: Boost process and C
    ... thousand small strings can make a big difference in RAM used, ... portion of the memory footprint and saving the memory that avoiding the ... flags would be of real use. ... of magnitude smaller and so could easily fit in with the extra overhead. ...
    (comp.lang.c)
  • Re: Flexible Collating (feedback please)
    ... Although it is still quite a bit slower than a bare list.sort, that is to be expected as collate is locale aware and does additional transformations on the data which you would need to do anyways. ... Changed the flag types from integer values to a list of named strings. ... The reason for this is it makes finding errors easier and you can examine the flags attribute and get a readable list of flags. ... It now separates numerals in the middle of the string. ...
    (comp.lang.python)
  • Re: tracking down disk spinups.
    ... I implemented the BusyBox mount command last year. ... (The new flags _replace_ the old flags, ... of course, not all of them are flags, some remain strings, but you can't keep ... (because otherwise the kernel got log message diarrhea). ...
    (Linux-Kernel)