[Kstars-devel] Speeding things up

[James Bowlin]

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.


Here is a trick we could try to make the stars load even faster than 
they are loading now, although it is possible this trick won't help.  
The Linux kernel is gzip compressed which usually makes loading the 
kernel faster.  The basic analysis is here:

http://elinux.org/About_Compression

The general idea is that CPUs are so fast nowadays that the time needed
to decompress is more than compensated by speeding up the I/O due to
a smaller file size.  The article suggests that alternatives be 
benchmarked.  It also says that if someone is already using a 
compressed filesystem then compressing our file again will only slow 
things down.  Still, we might get some performance boost by compressing 
our star data.  We wouldn't compress the whole file.  Instead, chunks 
of the file would be compressed so it could be decompressed in chunks.  


We might also be able to boost performance by using a different 
spherical mesh/index that divides the sphere into areas of equal size.
There can be a significant difference in sizes of trixels in the 
Hierarchical Triangular Mesh we are currently using.

We can probably also get an improvement by using different sized meshes
for differently sized star catalogs.  The improvements will only be seen
when catalogs of significant size (> one million perhaps) are used.


-- 
Peace, James