[Kstars-devel] design doc for million stars project
James Bowlin
bowlin at mindspring.com
Mon Jun 9 05:29:16 CEST 2008
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
More information about the Kstars-devel
mailing list