Hi Quincey,
The way you broke this down was very helpful, and it turned out to be a
combination of two things you alluded to. I'd been on the right track that it
had to do with NIB objects, and thinking about it as you laid out helped
identify the problem.
On 2011-01-23, at 12:28 AM, Quincey
On 2011-01-23, at 12:59 AM, Dave Keck wrote:
> On the other
> hand, if I understood you correctly in that you're seeing a 10%
> speedup when using GC, then perhaps that would warrant the extra
> effort. On the other-other-hand, it sounds like you might be
> optimizing early.
Sorry the comment ab
Sorry - I forgot to mention that I am indeed wrapping my code in its own
autorelease pool. This should ensure that the only retain count remaining is
from intentional retains by other objects that need to reference my datasets.
Rick
On 2011-01-23, at 12:59 AM, Dave Keck wrote:
> The autorele
Hi Quincy,
Thanks so much for the detailed reply.
On 2011-01-23, at 12:28 AM, Quincey Morris wrote:
>> [...]
>
> You *cannot* rely on GC to satisfy your timing requirements for releasing
> resources used by your application. You can't even rely rely on GC to release
> memory at all, in any d
On 2011-01-23, at 12:04 AM, Dave Keck wrote:
...
>>
> I would use gdb's "info gc-roots 0x" command to determine what
> strong references exist to the objects that are placed in your array.
> Instruments may also have some related functionality.
Thanks - I was focusing on Instruments, a
Thanks Scott,
On 2011-01-22, at 11:58 PM, Scott Ribe wrote:
> You might try something like usleep(1000) just to see what happens. You might
> not need any real delay; you might just need to yield...
Tried the above, but the GC version goes back to ballooning memory usage and
eventual crash.
> I worked up a version of our app that uses retain/release style memory
> management, and was surprised to note that a similar thing was happening
> (although the memory use did not get as big). Running a script that would
> send five sequential processing requests to the server, with a 'close
On Jan 22, 2011, at 20:27, Rick Hoge wrote:
> Of course I could also just put a sleep(1); in the code after removing
> references to the dataset objects and calling collectExhaustively, but this
> seems pretty crude and who knows if 1 second will be long enough for some
> ultra-large processing
> I'm pretty sure I'm not leaking the memory with an unintended reference, as
> the datasets *are* collected (albeit not very quickly) after I run a set of
> five operations and the server returns to be waiting for user input. I'm
> wondering if it could be because collection will not happen un
On Jan 22, 2011, at 9:27 PM, Rick Hoge wrote:
> Of course I could also just put a sleep(1); in the code after removing
> references to the dataset objects
You might try something like usleep(1000) just to see what happens. You might
not need any real delay; you might just need to yield...
Stil
On 2011-01-20, at 10:54 AM, Rick Hoge wrote:
[...]
> I have overridden the 'finalize' method of the dataset class to print a log
> message before calling [super finalize], and when I perform a single
> processing 'run' in which the client sends a message to the server directing
> it to load a
I have an application based on the "Cocoa Application" template in Xcode
(x86_64, currently testing on OSX 10.6.5) that listens for client messages
using an NSConnection. Both client and server have been designed for garbage
collection, and are compiled GC-only. The client is a simple command
12 matches
Mail list logo
