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 <[email protected]>: > > 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 <[email protected]>: >> >> >> > 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 <[email protected]>: >> >> 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, [email protected] wrote: >> >> >> >> ------------------------------------------------------------ >> >> revno: 4086 >> >> committer: Anton Gladky <[email protected]> >> >> 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 : [email protected] >> >> 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 : [email protected] >> >> Unsubscribe : https://launchpad.net/~yade-dev >> >> More help : https://help.launchpad.net/ListHelp >> >> >> > _______________________________________________ >> > Mailing list: https://launchpad.net/~yade-dev >> > Post to : [email protected] >> > 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 : [email protected] >> 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 : [email protected] > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
