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
Andy,
2 hours after after I sent replied yesterday I got everything to work, images,
clicking, and responses from actions. Thanks.
Sent from my iPad
On Apr 25, 2014, at 11:06 PM, "Andy Lee" mailto:ag...@mac.com>>
wrote:
On Apr 25, 2014, at 5:52 PM, "Peters, Brandon"
mailto:bap...@my.fsu.edu>
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
Le 18 avr. 2014 à 13:32, Frédéric Testuz a écrit :
>
> I have a typical CoreData application which display my entities in an
> NSTableView with an NSArrayController and a panel to edit the selected item.
>
> I have an entity Book with a NSString attribute type displayed in an
> NSComboBox. I w
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 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 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 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
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
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
> On Apr 25, 2014, at 10:35 AM, Seth Willits wrote:
>
>> On Apr 25, 2014, at 8:08 AM, Jens Alfke wrote:
>>
>> I’m ending up at the opposite of the received wisdom, namely:
>> * dispatch_sync is a lot cheaper than dispatch_async
>> * only use dispatch_async if you really need to, or for an expen
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
All,
New to Authorization, and it's got me a little turned around. Can someone post
a code snippet that shows how to us authorization services to run 'sudo chown'
from within Cocoa?
Thanks in advance!
Eric
___
Cocoa-dev mailing list (Cocoa-dev@list
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 12:02 , Kyle Sluder wrote:
> FWIW, I’ve been of the opinion for a while that including dispatch_sync in
> the API was a mistake. Too often it becomes a crutch used without
> understanding, resulting in stop-start behavior across threads or cores.
I don’t know if you’ll agr
Since you are interfacing with database maybe you can use a little transaction
interface which is its own thread and run loop. That may be able to cut down
your amount of syscalls. That is, not using GCD but old fashioned NSThread,
NSRunLoop (and CFRunLoop) and NSCondition.
OS X implemented GCD
You can write your own dispatch queue by using a CFRunLoopSource and add an
NSCondition to it when you need it to be synchronous (implementing
dispatch_sync)
Sent from my iPad
> On Apr 27, 2014, at 4:55 AM, Quincey Morris
> wrote:
>
>> On Apr 26, 2014, at 12:02 , Kyle Sluder wrote:
>>
>> F
On Apr 26, 2014, at 2:10 PM, ChanMaxthon wrote:
> Since you are interfacing with database maybe you can use a little
> transaction interface which is its own thread and run loop. That may be able
> to cut down your amount of syscalls. That is, not using GCD but old fashioned
> NSThread, NSRun
Weird. My old code used to be GCD heavy and even deadlocked once but new
projects that used old school methods are faster and never locked up. My
projects are heavy in network IO.
I built a transactional network interface there, which is somehow a clone of
Distributed Objects that is based on H
Also when you are using custom run loop sources (which is required here) pretty
much all code that is interfacing the run loop is CF code, so no Objective-C
method calls here (and the few remained ones can be IMP-cached so they are just
as fast.)
Sent from my iPad
> On Apr 27, 2014, at 5:36 AM
On Apr 26, 2014, at 5:36 PM, Jens Alfke wrote:
>> OS X implemented GCD at kernel level which introduced lots of syscalls which
>> are super expensive. The old school method is largely user land so it may
>> help a little by keeping syscalls to a minimum. @synchronized uses
>> Objective-C runt
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
Okay, here's a puzzling one... Here's my init method for the SKScene:
-(id)initWithSize:(CGSize)size
{
ERGPlayer *player = [[ERGPlayer alloc] init];
SKAction *tempAction = nil;
SKAction *waitAction = nil;
if (self = [super initWithSize:size])
{
self.currentBackground = [ERGBackground generate
Just because you are using Core Foundation interfaces doesn’t mean you aren’t
getting Objective-C code behind the scenes.
On Apr 26, 2014, at 2:44 PM, ChanMaxthon wrote:
> Also when you are using custom run loop sources (which is required here)
> pretty much all code that is interfacing the ru
On Apr 26, 2014, at 17:13 , William Squires wrote:
> I'd show you what this looks like, but I don't think users are supposed to
> post pics to this group.
You can post screen shots in the Developer Forums, and you’ll find more people
with SpriteKit experience there.
> Any ideas on how to iron
25 matches
Mail list logo
