Time Nick Message 12:09 sfan5 planning to merge #14707 later today 12:09 ShadowBot https://github.com/minetest/minetest/issues/14707 -- Call malloc_trim() regularly to improve deallocation behavior by sfan5 13:13 MTDiscord I did the thing 13:23 MTDiscord #14734 and let me know, etc 13:23 ShadowBot https://github.com/minetest/minetest/issues/14734 -- Add --terminal-silent flag to minetest by jordan4ibanez 18:18 MTDiscord sfan, I havn't replied again before you merged it, should I have reported back a second time or was it okay like this? 18:19 MTDiscord for context, the above is in response to: > https://github.com/minetest/minetest/issues/14707 -- Call malloc_trim() regularly to improve deallocation behavior by sfan5 18:20 sfan5 I assume that it still works, no need to test again 18:29 MTDiscord Thanks wsor, sorry for the messy message. Ah okay, yeah works - I havn't "benchmarked" it so I can't tell you if your later commits improved it or not but either way it's better than before. Thanks for your work! 19:42 MTDiscord Wait wat? I'm doing benchmark testing, and I'm trying to duplicate results on master and a branch. One of my more ridiculous things I try, is to delete a pseudorandom ID number. I'm getting different results for which actual object this deletes. Which makes me want to know: Is the active object ID assigned, not in order of 1,2,3... Immediately after startup? For example, is there somewhere that would cause it to start at 500 19:42 MTDiscord instead of 1... 19:48 MTDiscord I believe there is no guarantee by the active object mgr about what order IDs will be assigned in. 19:49 MTDiscord There may be a certain order in the current implementation, but that's not documented as being part of the contract, so if it is we need to add some unit tests for it and document it. 19:50 MTDiscord Okay, fair enough. So now how do I remove a randomized object, and remove the same one each time.... Across the two executions/branches... 19:52 MTDiscord Could you explain more about what you mean by removing a randomized object, but having it be the same one each time? 19:52 MTDiscord I don't usually thing of "randomized" and "same one" as going together. 19:52 MTDiscord think* 19:53 MTDiscord Maybe I should rename myself to Rubber Duck. 19:55 MTDiscord I am using pseudorandom number to determine when* to delete an object, add an object, move an object, and getobjects in radius and area. I do this many times to simulate fuzzy testing to ensure my branch and master have identical behavior. Right now, so make things a better test, 1/80 objects I find in radius or area, I delete the object ID two less than the found object. That ID, with identical test code, is resulting in a 19:55 MTDiscord different number. Master might delete 132, and my branch might try 543. This with everything else getting identical results, except object IDs. Since I cannot seem to rely on object IDs being identical, I have to write a slightly worse test, and delete the current object (1/80 times) regardless of ID, and hope that's a strong enough fuzz test. 19:57 MTDiscord Hmm, since the relative ordering of new IDs doesn't need to be the same between branches, I don't think it's something you need to test. I would think deleting the current object, or deleting a particular object you can identify some way, would be sufficient. 19:58 MTDiscord Could the unexpectedly large ID assignments be due to existing entities loaded from the database? 19:58 MTDiscord It'll have to be current. Because since I'm messing with objects in area and radius, I can't rely on that functionality haha 19:58 MTDiscord No: this is not a full startup, this is unit/benchmark testing, where I just create a new SAO manager in a c++ file and test in that sandbox 19:58 MTDiscord I haven't read that part of the code carefully, but I believe objects alive at runtime may be saved to the database and their IDs may even be saved with them, potentially. 19:59 MTDiscord Ok. 20:01 MTDiscord It could still load the entities. It may not be a full startup, but it pretty much runs in a fully initialized context. 😄 You are probably right that it won't. It's extremely unlikely in a unit test. I'm just noting for completeness that if the object manager does a database read and it happens to read an actual database somehow then boom. 20:01 MTDiscord If I've learned one thing about programming it's to never assume anything. 20:02 MTDiscord well, number of entities is identical in both: 1000,1000 20:04 MTDiscord I would be concerned that if the way the IDs are assigned has changed and you didn't intend to change it, then, well, you made a change you didn't mean to and that's probably not desirable. 20:05 MTDiscord For the purpose of the test, you shouldn't rely on it being the same, but if you didn't mean to change it and it was deterministic (which I believe it was) that's another matter. 20:17 MTDiscord Aha! it's a different order because my map is unordered when it returns a range.... 20:17 MTDiscord so.... hurm.... how to make this deterministic if the order is always jumbled... 20:29 MTDiscord there... is no good way is there.... well... I have 1000 entities. and I determined they do go from 1-1000 deterministically (normal for once). and I only add or remove 30 from each iteration... before redoing all 1000..... okay, I'll just remove a random one between 0-1000, if it exists 21:06 MTDiscord nope, since the ID's are jumbled, that doesn't work, because I move random sets of objects with randpos, which would be fine, but by deleting random ID's, I get different ordering for who is moved where, thereby affecting in_radius removals... sigh. I'll just get rid of deletes. Hopefully ordered results aren't required