[Kstars-devel] Ideas for reducing memory and CPU usage

[Jason Harris]

Hello,

I have two ideas which I'd like to run by the list for feedback, one to reduce 
memory usage and one to reduce CPU usage.  If they work out, these ideas 
should help us to increase the number of objects in our catalogs without 
impacting performance too much.

1) Trimming data from SkyObject and its derivatives.  Presently, all data 
related to SkyObjects are loaded on startup and stored throughout the life of 
the program, even though not all of the data is used frequently.  By removing 
infrequently-used data we may be able to significantly reduce the memory 
footprint.  My idea is that each SkyObject can store an integer that 
identifies the line position in the data file which contains its full data 
record, so that the data can be read from the file quickly, without 
searching.  For some objects like NGC/IC objects and stars, the integer would 
also need to encode which file contains the object's record.

Note that we already do this for the pixmaps of deep-sky objects drawn on the 
sky: these are read from disk when the object moves on-screen, and are 
deleted as soon as it moves off-screen.

So how much "infrequent" data can we offload?  It depends on the type of 
object:

All objects:
+ Catalog coordinates (the coordinates at J2000)
+ Name, Name2, LongName: we'd need to handle the object's label somehow if 
it's being drawn, maybe with a QString pointer that's deleted when it becomes 
unused.
+ ImageList, InfoList, ImageTitle, InfoTitle: read *_url.dat files from disk 
on-demand when opening Details or popup menu?  Store integers identifying 
lines in these files?  Or perhaps a separate url data file for each object?
+ UserLog text: read from disk on demand.

Stars:
+ Proper motion (RA and Dec), Parallax, bools for Multiplicity and Variability

Deep sky objects:
+ UGC and PGC catalog numbers, magnitude


2) Use interpolation to estimate X/Y coordinates.  Presently, each on-screen 
object requires relatively expensive trigonometric calculations to convert 
its RA/Dec or Az/Alt coordinates to pixel X/Y coordinates.  We may be able to 
save a lot of time by computing the X/Y coordinates for a uniform grid of 
RA/Dec positions that are on-screen, and then interpolating between these 
gridpoints to determine the X/Y coordinates of on-screen objects.

I'd have to determine the optimal grid density that will give us sub-pixel 
accuracy through interpolation while still reducing CPU usage.  This grid 
density would be zoom-dependent because the distortion of the map projection  
decreases at higher zoom levels.  Plus, at very high zoom levels it will 
likely be less expensive to just compute X/Y coordinates for the small number 
of on-screen objects, rather than do the interpolation.

Let me know what you think,
Jason

-- 
Jason Harris
jharris at 30doradus.org