[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-25 7:23:49
[Download RAW message or body]

On 6/24/99, 12:32:23 PM, Waldo Bastian <bastian@ens.ascom.ch> wrote 
regarding Re: QString or QCString for file names?:

> Pietro Iglio wrote:
> > 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.

> Are just the filenames stored or the full path? Are they stored
> as URLs?

Filenames are stored. The path is stored in the menu containing the 
items.
And filenames are not stored as URLS, as far as I remember.

> > 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.

> Let's see 4 filenames * 150 entries = 600 entries.

> With QString:
> Assuming an average length of 10 chars:
> Approx. 40 bytes per string.
> Approx. 24000 bytes.

> Assuming an average length of 30 chars (including path):
> Approx. 100 bytes per string.
> Approx. 60000 bytes.

> Possible memory use when using simple char *:

> Assuming an average length of 10 chars:
> Approx. 10 bytes per string.
> Approx. 6000 bytes. (Saves 18K)

> Assuming an average length of 30 chars (including path):
> Approx. 30 bytes per string.
> Approx. 18000 bytes. (Saves 42K)

> I don't think 42K is worth to bother. It would be if it could
> be saved in every application, but your normally run only 1 instance
> of kpanel anyway. If you have 1500 menu entries instead
> of 150 it could be worth it.

> Does that happen?

Well, it depends on how deep you go with kdisknav. Note that all 
kdisknav
menus are destroyed when they are closed, but if you allocate too much 
memory
with a long menu chain, the memory will never go back to the operating 
system.

However, you convinced me: saving 20k or 40k is not worth the effort.

> > > 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.

> I tried gprof some time ago but it doesn't really seem to understand
> the code very well.

My impression is that a profiler is not very helpful for interactive
applications.

-- Pietro

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