[Kstars-devel] Fwd: Re: Speeding things up

[James Bowlin]

On Воскресенье 07 июня 2009 00:50:49 James Bowlin wrote:
> On Sat June 6 2009, Alexey Khudyakov wrote:
> > Optimise SkyPoint constructors. Construct dmses using initializer
> > list istead of creating them first and overwriting them later.
> >
> > As funny it could appear this change measurably sped up kstars
> > startup. from 8800+/-300ms to 8450+/-100ms.
>
> Wow, that's great.  Any reduction in startup time is a help.
>
> If you have access to a KDE-3.5.x version of KStars (such as
> KStars-1.2.9) you will see that the startup time seems to be dominated
> by loading stars (especially with the faint limit set to 10.0).  In
> the  4.x versions of KStars, stars get loaded about 5 times or 10
> times  faster.  This is because of the binary loading mechanism which
> includes using memcpy instead of a constructor.
>
> IMO, for reducing startup time, the most bang for programming buck
> will be achieved by converting other components (comets, asteroids,
> etc) from ascii files over to binary files *perhaps* also with a
> memcpy construction.  Ideally we would still distribute the ascii
> files but include Perl programs that convert the ascii files into
> binary format. This will make it much easier for users to hack the
> data files. 
>
> I've looked into "placement new" again.  From what I can tell, there
> is no time difference between using "placement new" and a constructor
> so I suggest we keep using memcpy for stars but add copious comments
> explaining why it is used.

Placement new is useful if one want to allocate memory in chunks. Say 
allocate memory for 100 stars at once. And place that stars there.
Otherwise it give little or no speed advantage. 

Actually `new' could be faster that `memcpy'. It because memcpy use 
double copying: StarData -> StarTemplate -> Star. `New ' use only one. 
StarData->Star This should be carefully profiled. Otherwise it's all 
speculations. 

I think it's better to try to optimize constructors and all in order to 
bring perfomance on new/delete version to memcpy version. This remove 
possibility of rellay unpleasant surprises. And if it's proven to be 
impossible fall back to memcpy.


My attemts of profiling show that about 30% of startup time is spent in 
loading URL data. And findObjectByName calls. They turned out to be 
rather expensive. 

In addtion QString constructed/destroyed about 8e+6 times eating as much 
as 10% of time. So a lot of profiling is required I believe. 
Bottlenecks could occur in unexpected places.