[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: more questions
From:       Vladimir Dergachev <volodya () mindspring ! com>
Date:       2003-02-23 9:52:09
[Download RAW message or body]



On Sun, 23 Feb 2003, Philipp [iso-8859-1] Müller wrote:

> On Saturday 22 February 2003 23:14, Vladimir Dergachev wrote:
> > I have also been looking at QString.. It seems very large - am I being
> > mistaken here ?
>
> Hm, large in case of memory footprint, no.
> Yes in case of computation time.
>
> We haven't optimized here yet. QString is always the safest class, as it cares
> itself about memory and Unicode issues.
> In case it should be faster you can use sometimes QCString.
>
> Only in very rare cases we use plain c strings.
>

The reason I asked is because my experience suggests that one should avoid
calling memory allocator too often. I wrote small amount of C code that
implements small subset of what kspread does (needed for some computations
that needed to be able to use both strings and numbers) and I saw a large
perfomance increase when I allowed to embed small strings.

The way it worked is like this (C example):

Instead of

typedef  struct {
	char *data;
	} string;

One uses:

typedef struct {
	union {
	  char *data;
          char inlined_data[11];
	  } u;
        char type;
        } string2;

Then when one needs an array of these one allocates a bunch of string2 at
once, and, for small strings there is no need to make additional
allocations. In other words this makes sure that memory allocator is not
bothered with small allocations.

> > Is it reasonable to assume that an ASCII subset occurs more frequently
> > (numbers, etc) and non-ASCII characters are typically entered by hand ?
>
> As mentioned in the other mail: The values itself are already stored in a
> correct way. m_strText and m_strOutText can be principally eliminated.
>
> So what do you intend to do here?

I was thinking of trying to optimize a single class (maybe two) and
investigating the impact on perfomance. This is really on the level
between the C++ compiler and actual C code way below the rather complex
StyleManager/LayoutManager that was discussed.

Another way to look at this is that in C++ one can have usual fields in a
class (which take space) and #define's that do not take space. I would
like to see whether one can introduce a notion of semi-const - a field
which is assumed to change slowly than a regular field but faster than a
constant.

                       best

                         Vladimir Dergachev

>
> Philipp
> ____________________________________
> koffice mailing list
> koffice@mail.kde.org
> To unsubscribe please visit:
> http://mail.kde.org/mailman/listinfo/koffice
>
____________________________________
koffice mailing list
koffice@mail.kde.org
To unsubscribe please visit:
http://mail.kde.org/mailman/listinfo/koffice
[prev in list] [next in list] [prev in thread] [next in thread]