[Kstars-devel] Kstars optimization

[Prasanna Krishnamoorthy]

On 11/28/06, Jason wrote:
> Actually, the program might complain if you simply remove these files,
> so you can either modify the NHIPFILES value in kstarsdata.h, or you can
>    delete all the lines in each file above hip040.dat, but delete all of
> the lines in these files.
Great!! Thanks for the suggestion, I'll do this and see whether it is
acceptable.

>  > I also did some preliminary profiling with oprofile and kcachegrind,
>  > and the results were surprising! The most time(~50%) is spent in
>  > plastik.so,
> This is really surprising, especially since the main window has hardly
> any GUI elements!  What happens if you profile while using a style other
> than plastik?  My guess is there must be something wrong here that has
> nothing to do with KStars.
I'm using Xubuntu here, with Kstars installed. So I'm not quite sure
how to change the style :-). I'll find out how to do that. Is there a
'lighter' KDE style that you'd recommend?

> I've thought about this in the past.  It may be worth trying.  Again, at
> low zoom level extreme trig accuracy is probably unnecessary in most
> cases.  There will be situations when we want the real trig values, but
> in most cases, an interpolated grid should be good enough.
Great! I can get to work on that. Is there a list of situations where
'real trig' values are needed? I'm thinking of a wrapper function with
a run-time flag for 'real Vs fast'. Gcc should be able to optimize out
the function-call or inline it.

> A slight improvement over a static lookup table over the full range of
> angles is to dynamically create lookup table values for the range of RA
> and Dec values that are currently being displayed.  The advantage is
> that you can get a grid resolution that changes with zoom level, so it
> is always a good match to the pixel resolution.  The disadvantage is
> that it's more complicated, and you might need 4 lookup tables (for the
> displayed ranges in RA, Dec, Az and Alt).
I'll give a quick shot at the plain interpolated LUT first. I can
verify the standard error, over a default range, but am not sure how
we can quantify the error margin for Kstars correctly. Is there any
level which you'd consider 'acceptable', or perhaps this could be a
run-time option? Fast vs Accurate would be good for the user to choose
:-).

> Thanks a lot for the feedback.  Just so we can be clear of your intent,
> are you saying that you want to try implementing a lookup table, or are
> you just advocating the idea of doing so?
I'll work on the LUT as soon as I get some time - perhaps this week
itself. I need to get this up and running so the state can save as
much money on the hw as possible.

Will send you a patch as soon as I'm done with testing.

Thanks for the great work!
Prasanna.