[Imstk-developers] Mesh load factor

[Sreekanth Arikatla]

Sorry, all of my answers were assuming that preallocation to upper limit
was not the strategy. If one preallocates to the limit load factor makes
sense. I think it makes sense to set the upper limit to a certain factor of
the original size.

On Fri, Sep 29, 2017 at 4:30 PM, Milef, Nicholas Boris <milefn at rpi.edu>
wrote:

> Sorry, I didn't mean in mechanical or aeronautics. I was more pointing
> towards its use in CS, electrical, and passenger load factor. But if it's
> confusing we can choose a new name (e.g., maxStorageFactor).
>
> The limit doesn't change with each resize if that's what you're saying.
> You specify an upper limit (either an absolute limit or a scale from the
> original geometry, not sure which one is more appropriate). Then once you
> reach that limit, you get a warning and no more vertices can be added.
> ------------------------------
> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
> *Sent:* Friday, September 29, 2017 4:13 PM
>
> *To:* Milef, Nicholas Boris
> *Cc:* imstk-developers at imstk.org
> *Subject:* Re: [Imstk-developers] Mesh load factor
>
> I know what load factor means in mech/aero fields. There is a common theme
> to the definition of load factor in different fields and that doesn't seem
> to be applicable here. 'Load factor' definition in comp sci there seems to
> be in the context of hash tables, which seems apt.
>
> What I mean is if you end up with 20k verts from 10k with resizing 100
> times is different from that with resizing once. To overcome all of this
> one generally, does a preallocation with the upper limit of the
> expected size.
>
> On Fri, Sep 29, 2017 at 4:01 PM, Milef, Nicholas Boris <milefn at rpi.edu>
> wrote:
>
>> What do you mean by this?
>> ------------------------------
>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>> *Sent:* Friday, September 29, 2017 4:00 PM
>>
>> *To:* Milef, Nicholas Boris
>> *Cc:* imstk-developers at imstk.org
>> *Subject:* Re: [Imstk-developers] Mesh load factor
>>
>> The number of different instances the resizing happened also influences
>> the fragmentation.
>>
>> On Fri, Sep 29, 2017 at 3:56 PM, Sreekanth Arikatla <
>> sreekanth.arikatla at kitware.com> wrote:
>>
>>> sounds good. Can we call it 'resizing factor' then?
>>>
>>> On Fri, Sep 29, 2017 at 3:54 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>>> wrote:
>>>
>>>> Well, I was thinking of just having a limit. So if you load a mesh
>>>> that's 10k vertices, and it's load factor is 2x, then you can't add more
>>>> than 20k vertices.
>>>> ------------------------------
>>>> *From:* Sreekanth Arikatla [sreekanth.arikatla at kitware.com]
>>>> *Sent:* Friday, September 29, 2017 3:50 PM
>>>> *To:* Milef, Nicholas Boris
>>>> *Cc:* imstk-developers at imstk.org
>>>> *Subject:* Re: [Imstk-developers] Mesh load factor
>>>>
>>>> Can you explain a bit more? Do you plan to do a fresh allocation when
>>>> resizing mesh beyond a certain size to prevent fragmentation?
>>>>
>>>> On Fri, Sep 29, 2017 at 1:56 PM, Milef, Nicholas Boris <milefn at rpi.edu>
>>>> wrote:
>>>>
>>>>> What do you all think about a mesh load factor? I would like to add
>>>>> one to prevent a range of allocations issues (fragmentation, invalid
>>>>> allocations, etc.) when resizing a mesh. This would be able to be
>>>>> customized by the user of course.
>>>>>
>>>>> _______________________________________________
>>>>> Imstk-developers mailing list
>>>>> Imstk-developers at imstk.org
>>>>> http://public.kitware.com/mailman/listinfo/imstk-developers
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Sreekanth Arikatla, Ph.D.,
>>>> Senior R&D Engineer,
>>>> Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
>>>>
>>>>
>>>
>>>
>>> --
>>> Sreekanth Arikatla, Ph.D.,
>>> Senior R&D Engineer,
>>> Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
>>>
>>>
>>
>>
>> --
>> Sreekanth Arikatla, Ph.D.,
>> Senior R&D Engineer,
>> Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
>>
>>
>
>
> --
> Sreekanth Arikatla, Ph.D.,
> Senior R&D Engineer,
> Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
>
>


-- 
Sreekanth Arikatla, Ph.D.,
Senior R&D Engineer,
Kitware, Inc. <http://www.kitware.com>, Carrboro, NC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/imstk-developers/attachments/20170929/d44298d9/attachment-0001.html>