Jason,  this is great!  And the timing couldn't be better.  I think we
finally got the overall design fleshed out today.  

I've tried to answer your three outstanding questions below.  If you 
would prefer for me to answer directly on the Web page, PLMK.


On Sun June 8 2008, Jason Harris wrote:
> Do the bright/named stars go into StarBlocks as well, or are they kept
> in the current structure of StarIndex/StarList ? I think it's the
> latter, but I may have old information.

The plan today is to only put named stars in the current structure and
put the bright/global stars in custom sized StarBlocks that will be the
first StarBlock in each StarBlockList.

> Are we still considering loading the entire binary data file into
> memory, and dynamically parsing it as needed, or will we read chunks
> of the file from disk as the StarBlockLists need them?   

The current plan is to read all the named stars at start-up and also
read in the 50K brightest (global) unnamed stars at start-up.

After that, the dynamically loaded stars will only be read in on a 
strictly as-needed basis.  The only exception to this rule is that
for any given trixel we will usually read in one extra star because we 
stop reading when we get a star that is dimmer than the current 
mag_limit.

> What happens to the last StarBlock in a trixel, which will be
> partially filled 99% of the time? 

That will just be wasted space.  But if we only start loading the 
dynamic stars when there are six or fewer trixels visible, this wasted 
space will typically be about 300 stars worth and will always be less 
than 600 stars worth.  With a 1E6 catalog, we would have approximately 
2000 stars per trixel.  The wasted space at the end would be 50 stars 
per trixel on average.  This means only a 2.5% wastage, which I think 
is acceptable.  If we cut the number of stars per block down to 50 then 
the wastage is a little over 1%.  

This is one reason why we might want to let the users tune the number
of stars per StarBlock in the config UI.  There is a trade off.  Larger 
StarBlocks increase performance but waste more space.  Smaller 
StarBlocks conserve RAM but make the memory management overhead more 
expensive.

We would probably experiment a little to find out the optimal stars per
block for the default configuration.  It may well be something other 
than 100.


-- 
Peace, James
_______________________________________________
Kstars-devel mailing list
Kstars-devel@kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel