yade-dev team mailing list archive

[Anton Gladky <gladky.anton@xxxxxxxxx>]

Ok, agree. I will try to fix it in a couple of weeks.
If there are volunteers to do it, it is always welcome.

Anton


2014-09-16 20:01 GMT+02:00 Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>:
>
> although, I do not think, that the vector increasing with NULL-vectors
> will lead to a memory leakage,
>
> Even a pointer pointing to nowhere needs memory for the pointer itself.
> vector<ptr>(1000,NULL) is taking more memory than vector<ptr>(10,NULL), or
> it would be a big surprise for me.
> Actually it doesn't matter if the pointers are null or not, overall the
> memory that these vectors need is sizeof(ptr)*vector.size().
> Hence the memory leak.
> Plus many other vectors resized based on scene.bodies.size() and supposed to
> contain other things (bigger than a pointer in most cases), there are many
> occurences of this.
> Of course it would be even worst if the pointers were actually pointing to
> true bodies, them to would waste memory.
>
> We can return back the previous behavior, but I would want to have
> unique body ids. So, we need  to uncouple b.id and position as you
> suggested.
>
> I have a god feeling that it can bring us additional bugs, in cases, where
> body id is associated to its position. Not sure, how many of them are in
> the code.
>
> Avoiding bugs is why I suggested to use "label" for post-processing and "id"
> for index in bodies, not the other way.
> Body label will be unique, body id will not. If we do that we don't uncouple
> id and position.
> The recorders will have to be modified, so that they record labels instead
> of ids.
> The rest of the code will be back to the previous state. No bad bugs to be
> expected.
>
> Cheers
>
> Bruno
>
>
>
>
>
>
>
> Thanks
>
>
> Anton
>
> 2014-09-15 13:14 GMT+02:00 Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>:
>>
>>
>> > Do you observe some problems with this commit?
>> Mostly a memory leak, since the size of the vector is increasing
>> forever, and many other vectors alike.
>> For instance:
>>
>> https://github.com/yade/trunk/blob/5776b8923372d9e7563dee0756d4224f01a954a8/pkg/common/InsertionSortCollider.cpp#L234
>>
>> Also maybe bad performances in parallel sections, the collider
>> especially but not only, if the first 99% of scene.bodies are occupied
>> by null pointers.
>> Also some algorithms in Yade may assume that max id is the number of
>> bodies, but I have no precise examples of that. The problems will remain
>> hiden until someone use such algorithm in a simulation where bodies are
>> erased/created.
>>
>> A solution would be to uncouple b.id (the position in scene.bodies) and
>> b.label (the identifier in post-processing functions).
>>
>> Cheers.
>>
>> Bruno
>>
>>
>> 2014-09-15 11:20 GMT+02:00 Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>:
>> >> Hi Anton,
>> >> I'm a bit late on that one but... does it mean that the size ob
>> >> O.bodies is
>> >> increasing forever when bodies are deleted and added?
>> >> Bruno
>> >>
>> >>
>> >> On 17/07/14 10:14, noreply@xxxxxxxxxxxxx wrote:
>> >>
>> >> ------------------------------------------------------------
>> >> revno: 4086
>> >> committer: Anton Gladky <gladky.anton@xxxxxxxxx>
>> >> timestamp: Thu 2014-07-17 08:34:00 +0200
>> >> message:
>> >>   Disable reusing of removed body ids.
>> >>
>> >>   Some change in BodyContainer. Previously the ids of removed
>> >>   bodies could be reused by newly created particles. It caused
>> >>   some problems, for instance, by saving in VTK file and building
>> >>   pathlines of them in ParaView.
>> >>
>> >>   Also it could lead to some unexpected behaviour during intensive
>> >>   removal/adding particles.
>> >> modified:
>> >>   core/BodyContainer.cpp
>> >>   core/BodyContainer.hpp
>> >>
>> >>
>> >> --
>> >> lp:yade
>> >> https://code.launchpad.net/~yade-pkg/yade/git-trunk
>> >>
>> >> Your team Yade developers is subscribed to branch lp:yade.
>> >> To unsubscribe from this branch go to
>> >> https://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~yade-dev
>> >> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
>> >> Unsubscribe : https://launchpad.net/~yade-dev
>> >> More help   : https://help.launchpad.net/ListHelp
>> >>
>> >>
>> >>
>> >> --
>> >> _______________
>> >> Bruno Chareyre
>> >> Associate Professor
>> >> ENSE³ - Grenoble INP
>> >> Lab. 3SR
>> >> BP 53
>> >> 38041 Grenoble cedex 9
>> >> Tél : +33 4 56 52 86 21
>> >> Fax : +33 4 76 82 70 43
>> >> ________________
>> >>
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~yade-dev
>> >> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
>> >> Unsubscribe : https://launchpad.net/~yade-dev
>> >> More help   : https://help.launchpad.net/ListHelp
>> >>
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~yade-dev
>> > Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~yade-dev
>> > More help   : https://help.launchpad.net/ListHelp
>>
>>
>> --
>> _______________
>> Bruno Chareyre
>> Associate Professor
>> ENSE³ - Grenoble INP
>> Lab. 3SR
>> BP 53
>> 38041 Grenoble cedex 9
>> Tél : +33 4 56 52 86 21
>> Fax : +33 4 76 82 70 43
>> ________________
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> _______________
> Bruno Chareyre
> Associate Professor
> ENSE³ - Grenoble INP
> Lab. 3SR
> BP 53
> 38041 Grenoble cedex 9
> Tél : +33 4 56 52 86 21
> Fax : +33 4 76 82 70 43
> ________________
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-dev
> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>