[Kstars-devel] Binary star data loading accomplished in Branch!

Akarsh Simha akarshsimha at gmail.com
Mon Jun 2 22:49:14 CEST 2008


Hi

I did a few experiments commenting out bits of code in
StarComponent::readData(), trying to find out which block takes how
much time. I ensured that I emptied the kernel's cache before doing
anything. This is the picture I got:

+ Maximum time is taken by the StarObject constructor [James was
right, indeed!] and the appending of object names to the lists. We
should try to optimize the former. The latter can probably be ignored,
because we won't be having far too many named stars anyway. Each of
these take about 500 ms for 41560 stars = 12 usecs per star.

+ Next in the line comes the Trixel setup. This takes 300 ms for 41560
stars. This can be partially improved, so we will save about 4 usecs
per star. Currently it takes 7 usecs per star.

+ Next comes the reading of the name file. It takes about 150 - 200 ms
for 41560 stars, which is about 4 usecs per star.

As James rightly pointed out (and I wrongly posted), the StarObject
constructor seems to be taking the maximum time. Probably, we could
rewrite a StarObject constructor that takes in a struct starData and a
struct starName as input. That way, we'll be passing fewer arguments
to the function.

James, my major problem with doing the memcpy() is that QString s are
created in the constructor. Now, a QString must definitely do an
malloc() somewhere, to allocate memory for the string, which means
that there's a pointer involved. A memcpy() could simply duplicate
that pointer! Any solutions to that?

I'll try to analyze memory dumps of StarObject objects tomorrow.

Regards
Akarsh


More information about the Kstars-devel mailing list