John Engelhart wrote:
Again, thanks for the suggestion. It's pretty clever and elegant,
even if it does make swiss cheese of the code with #ifdef statements.
Would a #define'd macro (or macros) make it less cheesy?
Bracket the macro definitions with #ifdef's, as necessary.
-- GG
On Mar 14, 2009, at 3:29 , Paul Sanders wrote:
How about perl instead? (I don't think egrep is a fair test, it
doesn't have to 'do anything' with the results, like create a new
string from them). This is a rough perl equivalent of my original
problem:
I guess that's the point I was trying to
On Fri, Mar 13, 2009 at 11:21 PM, Peter Ammon wrote:
>
> I think you're saying that it's more convenient for you to work with a
> pointer than directly with an array. If so, another way you can defeat
> write barriers is with a cast to void*:
> void func(id *ptr) {
> ptr[0] = @"foo"; // <--- w
Ah, right, sorry. I'm not saying the existing API would permit such a
change, more's the pity. All I'm saying (and I doubt that saying
this has
any value) is that it could, and in my opinion should, have been
done that
way in the first place.
It's very tempting to try to enforce this in a
To bring this back around to the concrete...
First -- a very hearty and public THANK YOU to Sean for filing quality
bug reports that often include minimal examples. The community has
definitely benefited from your contributions to the bug database!
On Mar 14, 2009, at 11:17 AM, Sean McBrid
Paul Sanders (p.sand...@dsl.pipex.com) on 2009-03-14 6:29 AM said:
>I'm sorry Bill, but the more I hear about GC and in particular the
>difficulties of using it with malloc'd memory the gladder I am not to be
>using it.
My unsolicited 2¢: :)
I am happy that the GC implementation keeps GC memory
Bill Bumgarner (b...@mac.com) on 2009-03-14 12:40 PM said:
>On Mar 14, 2009, at 9:27 AM, Kyle Sluder wrote:
>> On Sat, Mar 14, 2009 at 12:22 PM, Bill Bumgarner wrote:
>>> On Mar 14, 2009, at 3:29 AM, Paul Sanders wrote:
>>> GC is similar to Core Data. If you had a Core Data app on Tiger,
>>> th
> But, heck, if you think it will serve your product's time to market
> better by focusing on the innards than the directly customer facing
> bits and then playing catch-up when Apple significantly advances the
> state of the art of similar technologies, well... bully for you!
I believe I mentione
>> Well, that's patently untrue. It can just return a temporary object with
>> a
>> retain count of 1.
> No, it can't. I specified a Get function, where convention specifies
> that the caller does not own it. Even if Apple were willing to break
> with convention, such a change would cause every e
On Mar 14, 2009, at 9:27 AM, Kyle Sluder wrote:
On Sat, Mar 14, 2009 at 12:22 PM, Bill Bumgarner wrote:
On Mar 14, 2009, at 3:29 AM, Paul Sanders wrote:
GC is similar to Core Data. If you had a Core Data app on Tiger,
there
were numerous operations on Leopard that were significantly faster
On Sat, Mar 14, 2009 at 12:22 PM, Bill Bumgarner wrote:
> On Mar 14, 2009, at 3:29 AM, Paul Sanders wrote:
> GC is similar to Core Data. If you had a Core Data app on Tiger, there
> were numerous operations on Leopard that were significantly faster -- many,
> many times faster -- that you got fo
On Mar 14, 2009, at 3:29 AM, Paul Sanders wrote:
I'm sorry Bill, but the more I hear about GC and in particular the
difficulties of using it with malloc'd memory the gladder I am not
to be
using it. I guess that one should not be surprised that it is
difficult to
retro-fit it in the way tha
On Sat, Mar 14, 2009 at 6:11 AM, Paul Sanders wrote:
>> If Apple later on wants to change how it works
>> internally so that the function returns a temporary object instead,
>> well, too bad, can't!
>
> Well, that's patently untrue. It can just return a temporary object with a
> retain count of 1
> How about perl instead? (I don't think egrep is a fair test, it
> doesn't have to 'do anything' with the results, like create a new
> string from them). This is a rough perl equivalent of my original
> problem:
I guess that's the point I was trying to get across - the overhead of
creating all t
> If Apple later on wants to change how it works
> internally so that the function returns a temporary object instead,
> well, too bad, can't!
Well, that's patently untrue. It can just return a temporary object with a
retain count of 1.
It comes down to a simple question of whether or not you a
On Fri, Mar 13, 2009 at 2:03 PM, Paul Sanders wrote:
>> Without any sort of management, you'd leak memory like
>> crazy in situations where neither the caller or the callee can release
>> the object.
>
> A scheme where it is always the caller's job to release any object returned
> to it is perfect
On Mar 13, 2009, at 7:59 PM, John Engelhart wrote:
On Fri, Mar 13, 2009 at 8:26 PM, Peter Ammon wrote:
http://c-faq.com/malloc/alloca.html for a rough idea why)
The goal is for the compiler to not use individual write barriers
at all,
and it won't for stack allocated buffers. So my sugg
On Fri, Mar 13, 2009 at 8:26 PM, Peter Ammon wrote:
>
> On Mar 13, 2009, at 4:47 PM, John Engelhart wrote:
>
>> On Thu, Mar 12, 2009 at 3:17 PM, Peter Ammon wrote:
>>>
>>> Hi John,
>>>
>>> Instead of storing each string individually into the heap, try batching
>>> up,
>>> say, 1k or so into a sta
On Fri, Mar 13, 2009 at 4:38 AM, Marcel Weiher wrote:
>
> On Mar 12, 2009, at 10:54 AM, Bill Bumgarner wrote:
>>
>> In the context of an application, such processing is likely to be on a
>> secondary thread and there is likely to be synchronization of data between
>> threads.
>> The overhead of t
On Fri, Mar 13, 2009 at 5:28 AM, Paul Sanders wrote:
> Bill said something in passing on this issue which I think is important. To
> paraphrase: If you care about performance, don't use the Cocoa RegEx stuff
> to parse large amounts of data.
I disagree :), and I have numbers to back it up:
(Reg
On Mar 13, 2009, at 4:47 PM, John Engelhart wrote:
On Thu, Mar 12, 2009 at 3:17 PM, Peter Ammon wrote:
Hi John,
Instead of storing each string individually into the heap, try
batching up,
say, 1k or so into a stack allocated buffer. Then use
objc_memmove_collectable() to move them in bu
On Thu, Mar 12, 2009 at 3:17 PM, Peter Ammon wrote:
>
> Hi John,
>
> Instead of storing each string individually into the heap, try batching up,
> say, 1k or so into a stack allocated buffer. Then use
> objc_memmove_collectable() to move them in bulk into the heap at the point
> your stack alloca
> Without any sort of management, you'd leak memory like
> crazy in situations where neither the caller or the callee can release
> the object.
A scheme where it is always the caller's job to release any object returned
to it is perfectly viable, as any number of other computing platforms (such
On Fri, Mar 13, 2009 at 1:30 PM, Paul Sanders wrote:
> That's very interesting, I didn't know that attribute existed. I imagine
> that post-dates autorelease pools by some years.
It's a relatively new GCC-ism.
> But most objects returned
> by framework functions are autoreleased which means you
> #define autoscoped __attribute__((cleanup(releaseObject)))
> static inline
> void releaseObject(id *object) {
>[*object release];
> }
> - (void) demo {
> autoscoped NSArray *myArray = [[NSArray alloc] init];
> //do some stuff
> }
> The autoscoped macro tags the lval with an attribute that
On Fri, Mar 13, 2009 at 12:04 PM, Paul Sanders wrote:
>
> (Off topic again): Call me old-fashioned, but I don't like autorelease pools
> all that much. I believe Cocoa could have gotten along just fine without
> them, had they never been invented. I prefer C++-style 'smart pointers'
> that delet
> The most complex change is the move from -dealloc to
> -finalize. Finalizers are executed in an effectively
> random order whereas many people seem to want deallocs to
> be executed in a fixed, dependent, order.
> In reality, incurring order dependencies on -dealloc is a really bad
> idea; on
On Mar 13, 2009, at 2:28 AM, Paul Sanders wrote:
Having said all of which, I think the original test is not unfair
and I
agree with a lot of the points people have made in support of that
view.
It's always painful to have to step outside the Cocoa frameworks,
and (off
topic) it seems that GC
Bill said something in passing on this issue which I think is important. To
paraphrase: If you care about performance, don't use the Cocoa RegEx stuff
to parse large amounts of data. I think this observation is true whether
you use GC or not. GC just makes it worse. I'd like to see a pure-C
ben
On Mar 12, 2009, at 10:54 AM, Bill Bumgarner wrote:
On Mar 12, 2009, at 10:29 AM, John Engelhart wrote:
Actually, this isn't a "micro-benchmark".
If you aren't displaying the results, responding to user events,
keeping an application state up to date and otherwise doing all of
the things
On Mar 12, 2009, at 8:39 AM, Bill Bumgarner wrote:
On Mar 12, 2009, at 6:04 AM, John Engelhart wrote:
[ way too many words deleted ... please try to succinctly
state issues in the future ]
You have created a micro benchmark that demonstrates a significant
bit of overhead from
On Mar 12, 2009, at 6:04 AM, John Engelhart wrote:
This is (obviously) due to -fobjc-gc turning the storing of a __strong
pointer in to a call to objc_assign_strongCast(). Each and every call
to objc_assign_strongCast, in turn, grabs a gc lock before it does its
work. Soo.. what was a simple
On Mar 12, 2009, at 10:29 AM, John Engelhart wrote:
Actually, this isn't a "micro-benchmark".
If you aren't displaying the results, responding to user events,
keeping an application state up to date and otherwise doing all of the
things that need be done in a real world application, it is -
On Thu, Mar 12, 2009 at 11:39 AM, Bill Bumgarner wrote:
> On Mar 12, 2009, at 6:04 AM, John Engelhart wrote:
> [ way too many words deleted ... please try to succinctly state
> issues in the future ]
>
> You have created a micro benchmark that demonstrates a significant bit of
> overh
On Mar 12, 2009, at 6:04 AM, John Engelhart wrote:
[ way too many words deleted ... please try to succinctly
state issues in the future ]
You have created a micro benchmark that demonstrates a significant bit
of overhead from GC vs. non-GC.
While micro benchmarks are certainly
35 matches
Mail list logo
