On 27 Apr 2014, at 23:01, Glenn L. Austin wrote:
>
> On Apr 26, 2014, at 10:32 AM, Dave wrote:
>
>>> Autorelease isn't causing your problem, it's that you're misunderstanding
>>> what autorelease pools are and do. What Dave wrote is correct: it was
>>> your loop that was causing the memor
On 26 Apr 2014, at 9:29 pm, Dave wrote:
> needed 10 MB!
> 150MB!
> pools!
> undo it!
> no drains!
>
> bad news!
>
> that’s dogma!
> 110 MB difference! Amazing!
> it’s naff
>
> Cheers
> Dave
I think there's some merit in discussing the design decisions in Cocoa that we
have to live w
I think that tight loop may be one thing, the appropriate scoping of variables
is another. When writing loops I tend to use lots of local variables that is
alloc/init'd and that will give clang an extreme good idea about what is going
on when the loop folds and variables all go out of scope. I d
On Apr 26, 2014, at 10:57 AM, Jens Alfke wrote:
>
> Yes, there are mainstream garbage-collected platforms now like Android and
> .NET. Guess what, in those you also have to spend time baby-sitting memory
> management, when you diagnose why your app’s heap size explodes during some
> operation
I think (from my experience of some junior developers in my realm) some of
these expectations comes from the progression of how autocomplete writes
your code for you in Xcode, so if it leaves something off, it’s Xcode’s
fault.
I personally don’t agree, and I delay the timing for autocomplete. Xco
At least for me, I do think in terms of how autorelease works. Its second
nature. The moment I see a loop of any kind, I think about a temporary pool of
objects and if I should do something about it. I just simply have no issues
with autorelease and think of it as a great feature that I use with
On 4/26/2014, 10:48 AM, "Jens Alfke" wrote:
Autorelease is a great example of There Ain't No Such Thing As A Free
Lunch. (TANSTAAFL)
I can see a new T-shirt with the saying (unless someone else already
thought of it like the Exercise becomes Eggs Are Sides for Bacon):
[T]here [A]in't [N]o [S]u
On Apr 26, 2014, at 4:29 AM, Dave wrote:
> Yes, because of autorelase! Take autorelase out of the equation and it doen’t
> use 150MB!
Autorelease is a great example of There Ain't No Such Thing As A Free Lunch.
(TANSTAAFL)
Before you gripe any further about it, I invite you to build a ref-
On Apr 26, 2014, at 10:32 AM, Dave wrote:
> Really, what OS other, makes you clean up after it?
Um.
You were making a joke, right? Or do you honestly think that Win32 or GTK or
POSIX or whatever don't require some attention to memory management?
Have you ever heard of malloc() and free()? Add
On 26 Apr 2014, at 15:40, Glenn L. Austin wrote:
> On Apr 26, 2014, at 4:29 AM, Dave wrote:
>
>>
>> On 26 Apr 2014, at 08:27, Jim McGowan wrote:
>>
>>>
>>> On 25 April, 2014 5:45:24 pm HKT, Dave wrote:
>>>
It’s not dogma! autorealease meant my App peaked at 150MB, whereas it
On 26 Apr 2014, at 08:27, Jim McGowan wrote:
>
> On 25 April, 2014 5:45:24 pm HKT, Dave wrote:
>
>> It’s not dogma! autorealease meant my App peaked at 150MB, whereas it needed
>> 10 MB! Autorelease caused 140 MB of data to be useless held in memory for
>> the duration of the Thread for no
On 25 April, 2014 5:45:24 pm HKT, Dave wrote:
> It’s not dogma! autorealease meant my App peaked at 150MB, whereas it needed
> 10 MB! Autorelease caused 140 MB of data to be useless held in memory for the
> duration of the Thread for no good reason.
>
‘Autorelease’ wasn’t causing your app t
On 25 Apr 2014, at 04:45, Graham Cox wrote:
>
> On 25 Apr 2014, at 11:24 am, Dave wrote:
>
>> I always knew autorelease was bad news!
>
>
> No it isn't, at least not inherently.
Inheriently it leads to data dependant methods/code and that is definitely bad
news.
> But if you don't proper
On 25 Apr 2014, at 11:24 am, Dave wrote:
> I always knew autorelease was bad news!
No it isn't, at least not inherently. But if you don't properly understand it
then it can bite you. You've trodden this path before, and I don't want to
rehash all that, but you were wrong then as well. If you
On a more positive note, thanks to yours and others help, I’ve sorted my Memory
issues.
I got rid of the leaks (most if not all!), after that running a download test,
showed that memory peaked at 150+ MB.
After fishing about and changing every method in the call chain to conform to
new/alloc n
Sorry - got out of bed the wrong side this morning. I'm happy the bug report
was of some use. Leaks is a great tool, especially the graph, would be a shame
if what seem like relatively small bugs lead to the impression that "it just
doesn't work right". Perhaps few people are as KVO junkie as me
Thanks for the bug report. If you could see rdar://10109782, you'd see that
your report prompted a new discussion about the priority and schedule for this
bug.
On Apr 24, 2014, at 4:09 PM, Roland King wrote:
> "Engineering has determined that your bug report (16683382) is a duplicate of
> an
"Engineering has determined that your bug report (16683382) is a duplicate of
another issue (10109782) and will be closed."
.. that wasn't very worthwhile was it.
On 22 Apr, 2014, at 12:49 pm, Roland King wrote:
> There you go. 16683382
>
> On 22 Apr, 2014, at 2:55 am, Greg Parker wrote:
>
There you go. 16683382
On 22 Apr, 2014, at 2:55 am, Greg Parker wrote:
> On Apr 20, 2014, at 3:40 PM, Roland King wrote:
>> If however one of A or B happens to be KVO'ing the other, which happens a
>> lot in my code, I use KVO everywhere, Leaks doesn't find the cycle. That's
>> wrong, KVO doe
On 22 Apr, 2014, at 3:34 am, Dave wrote:
> Confusing results.
>
> I changed the property in question:
>
> @property (nonatomic,assign) id payloadObject;
>
Start with this - what do you want that property to be?
Strong/weak/unsafe_unretained?
Second - allocati
On Apr 21, 2014, at 5:18 PM, Kevin Meaney wrote:
> On 21 Apr 2014, at 21:09, Andy Lee wrote:
>>
>> The solution is to use a weak reference for one of the properties in the
>> cycle. In general, if one object conceptually "owns" the other, then the
>> "owning" object uses a weak reference an
On 21 Apr 2014, at 21:09, Andy Lee wrote:
>
> The solution is to use a weak reference for one of the properties in the
> cycle. In general, if one object conceptually "owns" the other, then the
> "owning" object uses a weak reference and the "owned" object uses a strong
> one. For example, a
On Apr 21, 2014, at 10:53 AM, Alex Zavatone wrote:
>
> On Apr 21, 2014, at 10:34 AM, Andy Lee wrote:
>
>> On Apr 21, 2014, at 8:27 AM, Dave wrote:
>>> Also, when I did this, I left the property attributes as “retain” and
>>> “assign”, I’m wondering if it would be better to change them to “stro
Confusing results.
I changed the property in question:
@property (nonatomic,assign)id payloadObject;
Ran leaks again and it reported another cycle - same thing, so I fixed that one
too and ran leaks again, which now shows no cycles/leaks.
Before when the test f
On Apr 20, 2014, at 3:40 PM, Roland King wrote:
> If however one of A or B happens to be KVO'ing the other, which happens a lot
> in my code, I use KVO everywhere, Leaks doesn't find the cycle. That's wrong,
> KVO doesn't make a strong reference, as you can tell from the 'freed when KVO
> was s
On 21 Apr 2014, at 15:53, Keary Suska wrote:
> On Apr 21, 2014, at 8:12 AM, Dave wrote:
>
>> @property (nonatomic,retain) id payloadObject;
>>
>> This is after I ARCed it, before that it didn’t specify it, e.g. it was
>> (nonatomic). I must have made it retain whe
On Apr 21, 2014, at 10:34 AM, Andy Lee wrote:
> On Apr 21, 2014, at 8:27 AM, Dave wrote:
>> Also, when I did this, I left the property attributes as “retain” and
>> “assign”, I’m wondering if it would be better to change them to “strong” and
>> “weak” ? Although, AFAIK this shouldn’t make a di
On Apr 21, 2014, at 8:12 AM, Dave wrote:
> @property (nonatomic,retain) id payloadObject;
>
> This is after I ARCed it, before that it didn’t specify it, e.g. it was
> (nonatomic). I must have made it retain when I was going through the
> properties. I’m not sure w
On Apr 21, 2014, at 8:27 AM, Dave wrote:
> Also, when I did this, I left the property attributes as “retain” and
> “assign”, I’m wondering if it would be better to change them to “strong” and
> “weak” ? Although, AFAIK this shouldn’t make a difference?
For object properties, "strong" is a synon
On Apr 21, 2014, at 10:12 AM, Dave wrote:
> There is a delegate handler which makes passing and calling simple delegates
> a doddle. This was originally non ARC.
>
> There is a property defined:
>
> @property (nonatomic,retain) id payloadObject;
>
> This is after
Hi,
Amazing! I ***think*** I’ve found it! You were right, The profiler/leaks
analyzer works really well, thanks for the tips!
myNetworkOperation.pResponseNetworkDelegate or the corresponding class was the
culprit!
There is a delegate handler which makes passing and calling simple delegates
myDataTask has a block which retains self, and self retains myDataTask leading
to a cycle, would be my first thought. If nothing else also holds onto that,
you'd expect leaks to find it and give you a nice diagram showing how it all
hangs together, I believe leaks tracks dispatch_* (although I'v
On 21 Apr 2014, at 12:04, Roland King wrote:
>
> On 21 Apr, 2014, at 6:45 pm, Dave wrote:
>
>>
>> It does use isKindOfClass, I wasn’t trying to be 100% correct on the fluff,
>> just showing giving an example of the type of thing going in in property
>> assignment.
>>
>> I didn’t write tha
On 21 Apr, 2014, at 6:45 pm, Dave wrote:
>
> It does use isKindOfClass, I wasn’t trying to be 100% correct on the fluff,
> just showing giving an example of the type of thing going in in property
> assignment.
>
> I didn’t write that part it was like that and by all account it sort of
> wor
On 20 Apr 2014, at 21:32, Quincey Morris
wrote:
> On Apr 20, 2014, at 13:22 , Dave wrote:
>
>> This App was an iOS application and previously it handled manual memory
>> management - mostly using autorelease. I converted it by hand (didn’t use
>> the ARC coversion process).
>
> Ah, then i
On 21 Apr, 2014, at 3:51 am, Jens Alfke wrote:
>
> On Apr 20, 2014, at 11:58 AM, Cody Garvin wrote:
>
>> Second, while using instruments use the “mark heap” tool. Get your app up
>> and running. Mark the heap. Then start your image downloads, while that is
>> transpiring, mark the heap agai
On Apr 20, 2014, at 13:22 , Dave wrote:
> This App was an iOS application and previously it handled manual memory
> management - mostly using autorelease. I converted it by hand (didn’t use the
> ARC coversion process).
Ah, then ignore everything I said. :)
> if ([prop1 class] == [NSDictiona
Hi,
This App was an iOS application and previously it handled manual memory
management - mostly using autorelease. I converted it by hand (didn’t use the
ARC coversion process).
As for running the Static Analyser, I did run this and it showed no leaks, but
some dead stores. I have just run it
On Apr 20, 2014, at 11:58 , Cody Garvin wrote:
> Second, while using instruments use the “mark heap” tool.
> Third, keep in mind that blocks keep strong references to self (especially
> callbacks).
While these are important debugging steps, I’d suggest that this isn’t the
place to start *in t
On Apr 20, 2014, at 11:58 AM, Cody Garvin wrote:
> Second, while using instruments use the “mark heap” tool. Get your app up and
> running. Mark the heap. Then start your image downloads, while that is
> transpiring, mark the heap again. This will help narrow down the code that
> could possib
Hi Dave!
First, check to make sure zombies are disabled. I made the mistake of trying to
track down leaks via instruments, and totally forgot they were enabled: wild
goose chase.
Second, while using instruments use the “mark heap” tool. Get your app up and
running. Mark the heap. Then start yo
Hi,
I have a inheriated an Application that I converted to use ARC. When I run it
now, I see that memory is being allocated and not released. At least, when I
run the App with the debugger view active, I see the memory growing and growing
when I do some intensive Image Downloads as a test for t
42 matches
Mail list logo
