Subject:
|
Re: Some secrets of MLCad revealed ...
|
Newsgroups:
|
lugnet.cad.mlcad
|
Date:
|
Mon, 7 Jul 2003 23:03:25 GMT
|
Viewed:
|
4004 times
|
| |
|
|
In lugnet.cad.mlcad, Larry Pieniazek wrote:
> In lugnet.cad.mlcad, Damien Guichard wrote:
> > In lugnet.cad.mlcad, Michael Lachmann wrote:
> > > "Damien Guichard" <damien.guichard@wanadoo.fr> schrieb im Newsbeitrag
> > > news:HHKMxB.225G@lugnet.com...
> > > <SNIP>
> > > > Thanks Michael.
> > > > So, at loading time, each added point has to be compared to all points in the
> > > > point list. Does this impact the loading time of big parts or big models in a
> > > > significant manner? Or is it only minor slowdown?
> > > >
> > > > Regards,
> > > >
> > > > Damien
> > >
> > > So far I could find out, it doesn't effect loading much, I think it was
> > > something about 10% less then without this feature. I must say, I haven't
> > > tried using hash algorythms to find the point more quickly, but so far I
> > > remember there is an average of arround 400 points in a file, and search for
> > > an 12 byte value is not so hard ...
> > >
> > > Michael
> >
> > Ok, the practical figures relativize the problem for everyday use.
> > Thanks Michael.
> >
> > For the sake of sharing here is how I imagine a sorted point list.
>
> <snip>
>
>
> Cool! Should perform a lot faster on searching I would expect
>
> 400 points? That seems low to me. Most of my models have more than that many
> elements! Even with shared vertices that seems low.
I guess points are shared only on a part basis, not on a model basis.
So, 400 distinct points for a part is already a fair number.
Thus I think the sorting technique I discuss is not candidate for implementation
unless the ldraw library goes for many bigger part files, which is not the case.
There are some big part files on the PT (such as part 3947) but not many.
Also:
* the binary tree I discuss is not balanced and the method has to be
competitively compared with hashing
* I trust Michael and less than 10% better loading time doesn't seem much a
performance boost to me (rendering time is more important, even more if your
models have 400+ parts)
* last but not least, press for implementation is far from my mind as it's a
real pest for software authors, it often adds distraction and can impede
creativity and innovation
Yet the method still retains elegance and a certain applicability (may be in a
different area), so I wanted to share the idea.
Regards,
Damien
|
|
Message is in Reply To:
 | | Re: Some secrets of MLCad revealed ...
|
| (...) <snip> Cool! Should perform a lot faster on searching I would expect 400 points? That seems low to me. Most of my models have more than that many elements! Even with shared vertices that seems low. (21 years ago, 7-Jul-03, to lugnet.cad.mlcad)
|
12 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
