Memory filling up
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/09/2008 at 07:04, xxxxxxxx wrote:
Have you checked how much memory your private data is using? Have you tracked the number of CopyTo calls and what flags are flags send? Anyway I asked the developers about the CopyTo flags because I don't know if some are treated specially.
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/09/2008 at 07:11, xxxxxxxx wrote:
Hi Matthias,
it´s dynamic data, it fully depends on the user defined settings. It can be 10KB and it can be 100MB.
As I said, when the flags are NO_BRANCH and NO_HIERARCHY and I don´t copy, everything is fine. No memory fill up. (although the destination node does not have the data then).
The flags are sent when I change an AM setting and when I do an undo, so I concluded that it´s the undo buffer the destination node belongs to.
thanks. Waiting for info from devs.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/09/2008 at 05:53, xxxxxxxx wrote:
Any news on this yet?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/09/2008 at 06:20, xxxxxxxx wrote:
I will post as soon as I have an answer from our developers. One more question, is it always a constant amount of memory that is filling up? Otherwise it could be really just the undo buffer.
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/09/2008 at 07:11, xxxxxxxx wrote:
Nope, it´s dynamic according to my dynamic data. Never the same definetly. It´s that I MUST release tommorrow and there is no way around it. So it´s quite urgent to know if it´s fixable.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/09/2008 at 07:18, xxxxxxxx wrote:
Well in that case it seems to me quite logical that it uses that much memory. I mean if I have an object with lots of polygons it will also fill up quite quickly if I copy it several times. I am sorry that I can not be of much more help here as I have also to wait and see if the developers have something to say about it.
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/09/2008 at 07:28, xxxxxxxx wrote:
Yeah, I know. I am probably a little bit in panic and get impatient. I know you have to wait too.
Well, thanks for your opinion at least. I do some more tests in the meantime. It´s frustrating that activating a bool element will put another 50MB into the undo buffer (I don´t even copy the object, it´s just changing any AM setting will put that memory in RAM, even if that setting will e.g. only change the drawing options of my object).
If it was only the case when I copy my object in OM for example, that would be nice!
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/09/2008 at 07:35, xxxxxxxx wrote:
Quote: _It´s frustrating that activating a bool element will put another 50MB into the undo buffer (I don´t even copy the object, it´s just changing any AM setting will put that memory in RAM, even if that setting will e.g. only change the drawing options of my object).
>
> * * *
_
Ok, I see your point. Maybe introduce some checks what has changed in your object, for instance if there was only a change of some parameters that don't affect your private data don't copy it.
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/09/2008 at 07:42, xxxxxxxx wrote:
yep, I am already doing that in combination with those two flags now, however that´s only "a drop on a hot stone" :o/
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/10/2008 at 09:06, xxxxxxxx wrote:
Well, I hope I do get an answer BEFORE the support goes on the Roadshow and I don´t have to wait another 3 weeks for an answer that should be answerable (does that word exist at all) within 5 minutes if a programmer would take the time to look this up instead of drinking a coffee (the hell, he can even drink the coffee while looking it up!) *cough* thx
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/10/2008 at 09:21, xxxxxxxx wrote:
Copying of the private data should not depend on the flags.We would need some source code that shows the problem. You can also build your own memory managment with reference-counting (protected with semaphores), meaning you link the memory of your private data.
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/10/2008 at 09:27, xxxxxxxx wrote:
You need source? ok here is an example that is exactly the same:
myobject
{
private:
MyData* data;
}CopyTo()
{
if(dst.data==NULL)
dst.data = gNew MyData(data);
}That´s all about it, just with a different amount of data. There are also no magic or absurd data types, I use C++ Standards in all my code and C4D SDK Datatypes/typedefs only! No external libs of any kind or similar either.
So what´s the deal? I really don´t do any magic there. If an object of mine is not allocated, I allocate it. That´s all. It´s all only allocation and initialising of the data. No other processes, no running of any other code to make it initialise. Just usual allocation using C4Ds memory allocators (gNew/bNew).
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 15/10/2008 at 10:09, xxxxxxxx wrote:
Any information what the problem may be now?
I double checked my code and I don´t have any clue what may cause this. No double allocations, no missing memory freeing.I also wonder why it works with certain flags and with other flags it shall not work. Doesn´t make much sense to me (especially when you say it´s not up to the flags. Then it should work identical for all flags).
Either there is a code problem, then it would show up for every flag not only for these two I mentioned, or there isn´t, and it wouldn´t show up.