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

List:       kstars-devel
Subject:    Re: [Kstars-devel] Binary star data loading accomplished in Branch!
From:       Akarsh Simha <akarshsimha () gmail ! com>
Date:       2008-06-02 20:50:39
Message-ID: 20080602204914.GA18811 () PENGUIN
[Download RAW message or body]

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
_______________________________________________
Kstars-devel mailing list
Kstars-devel@kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
[prev in list] [next in list] [prev in thread] [next in thread]