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

List:       kde-devel
Subject:    Re: QString or QCString for file names?
From:       iglio () fub ! it (Pietro Iglio)
Date:       1999-06-24 6:50:47
[Download RAW message or body]

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 6/23/99, 11:28:27 AM, Waldo Bastian <bastian@ens.ascom.ch> wrote 
regarding Re: QString or QCString for file names?:

> > Pietro Iglio wrote:
> > I'm trying to optimize kpanel resource requirements (memory/cpu
> > usage). There are many string operations on file names
> > (concatenation, substring, etc),
> > that are performed on QStrings. I was wondering if we can gain
> > something replacing QStrings with QCStrings wherever it is
> > possible.

> Memory optimization and CPU optimization are two seperate things.

> With respect to memory:
> How does kpanel store filenames? How many filenames does it
> store?

There is at least a filename stored for each menu entry, both in the 
application menu and
in the kdisknav menu, plus two pixmaps names (large/small) and a 
comment for each entry.
If you use intensively kdisknav you can easily allocate, eg., 150 menu 
entries. Considering
an average length of 10 chars for each filename, you can save 
something if you don't
use QString.
BTW: it is my understanding (I'm wrong?) that QString allocates the 
unicode string (2
bytes for each char) + the ascii string if a method like 
QString::latin1() is invoked.
This means that a C string of 10 characters can take 10 * 2 + 10 + 
sizeof(QString) bytes.
This is why I'm trying to remove QString if it is not needed.

> With respect to CPU:
> Profile your code to see where the problems are. Guessing about
> performance problems is plain stupid. (Though very populair)

You are right, this is the general rule. However, it is not really 
easy to profile the
time spent for all qstring operations, unless you have a block 
profiler.

-- Pietro

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