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

List:       koffice
Subject:    Re: more questions
From:       Norbert Andres <nandres () web ! de>
Date:       2003-02-27 23:24:10
[Download RAW message or body]

Vladimir,

just to make sure: I have already started implementing the styles (as 
mentioned earlier in this thread). If no car hits me this weekend I will have 
the code in CVS by the middle of next week.
This is not the perfect solution yet (I hope you can help with that :-) but 
has a number of advantages
- speed when creating many cells (e.g. inserting a series)
- less memory usage (just one default layout and not one in every cell if the 
layout didn't get changed)
- first step to hierarchical styles like in OpenCalc - if we want to switch to 
the OpenCalc file format in the future this is also a first step
- we can add Custom Styles (like in Excel/OpenOffice,...) and enhance the 
conditional cell attributes with them (as wished in bugs.kde.org)

As soon as parts of the layout get changed, each cell gets its own layout 
object. In a style I included font settings, borders, colors but no number 
formats. This can be changed later easily and this is just a first useable 
step (and shouldn't screw up anything else).

The next step would be to create styles based on the default style which only 
contain the difference to it. So if a cell gets e.g. a bold font, a new style 
gets created (if none identical already exists), which is based on Default 
and saves a bold font attribute. This one can be reused by other cells (or 
columns/rows).
I don't know how far we want to go in cloning the OpenCalc file format (and 
can go, because of lack of developers) but I see this is a very important 
part.

Regards
Norbert

On Sunday 23 February 2003 10:52, Vladimir Dergachev wrote:
> 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

____________________________________
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]