On 22 May 2020, at 21:59, Aandi Inston wrote:
1. I wonder if your tests are in a non-English language system.
No, running on a non-localized system, and the evidence is overwhelming
that this is about SIP / AMFI (based on inspecting the stack trace,
which clearly show communication between t
> On May 22, 2020, at 8:42 AM, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 23 Apr 2020, at 21:15, Rob Petrovec wrote:
>
>> If what you say is correct then everyone would be seeing a delay since most
>> people don’t have blazing fast internet connections. I do not think this is
>> the norma
Your report is interesting. I have been following it but may have missed a
part of the discussion, so here is one
thought I had. You say that getting the display name of ~/Documents may
result in a delay. This is localizable, so
that in Portugal (for example) the display name is Documentos. So here
On 23 Apr 2020, at 21:15, Rob Petrovec wrote:
If what you say is correct then everyone would be seeing a delay since
most people don’t have blazing fast internet connections. I do not
think this is the normal behavior. I think it is specific to your
system, otherwise there would be TONS of p
Also, did you take advantage of one of your free tech support incidents?
--
Gary L. Wade
http://www.garywade.com/
> On Apr 24, 2020, at 8:26 AM, Gary L. Wade via Cocoa-dev
> wrote:
>
> That’s a very narrow view of reality, which I know to be far broader.
>
> What’s the feedback number?
> --
>
That’s a very narrow view of reality, which I know to be far broader.
What’s the feedback number?
--
Gary
> On Apr 24, 2020, at 8:01 AM, Allan Odgaard via Cocoa-dev
> wrote:
>
> That said, I *have* filed a report about this, but I still seek more
> information about the issue, which I had hop
On 24 Apr 2020, at 21:33, Gary L. Wade wrote:
Here’s two web sites that should help you get the answer you want.
Try one or both:
https://feedbackassistant.apple.com/welcome
https://www.apple.com/jobs/us/
You don’t get answers from filing bug reports with Apple, at best, the
issue gets clos
Here’s two web sites that should help you get the answer you want. Try one or
both:
https://feedbackassistant.apple.com/welcome
https://www.apple.com/jobs/us/
--
Gary
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requ
Allan,
> On Apr 24, 2020, at 00:14, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 24 Apr 2020, at 9:51, Gary L. Wade wrote:
>
>> Have you tried a speed check with just iCloud turned off but internet on?
>
> I have tried with iCloud disabled, internet disabled, and SIP disabled.
Have you tried
On 24 Apr 2020, at 11:49, Saagar Jha wrote:
GateKeeper is basically Safari adding a quarantine flag […]
Nit: not just Safari; other applications do this to at their
discretion when appropriate (for example, if they too download files
from the internet). Quarantine is just one part of GateKeepe
Saagar Jha
> On Apr 23, 2020, at 21:26, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 24 Apr 2020, at 9:57, Rob Petrovec wrote:
>
>>> Also weird, why would it phone home for a shell script which has neither
>>> been stapled nor even code-signed?
>> I think you answered the question just then…
On 24 Apr 2020, at 9:57, Rob Petrovec wrote:
Also weird, why would it phone home for a shell script which has
neither been stapled nor even code-signed?
I think you answered the question just then… a "shell script which
has neither been stapled nor even code-signed”. Google XProtect &
Gateke
On 24 Apr 2020, at 9:51, Gary L. Wade wrote:
Have you tried a speed check with just iCloud turned off but internet
on?
I have tried with iCloud disabled, internet disabled, and SIP disabled.
Only the latter two removes the delay. Also, the issue happens for
~/Downloads which is not an iCloud
>> Also weird, why would it phone home for a shell script which has neither
>> been stapled nor even code-signed?
> I think you answered the question just then… a "shell script which has
> neither been stapled nor even code-signed”. Google XProtect & Gatekeeper.
1) The executable part of
> On Apr 23, 2020, at 8:35 PM, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 24 Apr 2020, at 2:28, Gabriel Zachmann via Cocoa-dev wrote:
>
>>> I believe that is why you are supposed to staple notarization tickets to
>>> your apps.
>> Then, why would it "phone home" in case there is an internet
Have you tried a speed check with just iCloud turned off but internet on?
--
Gary
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)l
On 24 Apr 2020, at 2:28, Gabriel Zachmann via Cocoa-dev wrote:
I believe that is why you are supposed to staple notarization tickets
to your apps.
Then, why would it "phone home" in case there is an internet
connection?
Also weird, why would it phone home for a shell script which has neither
> On Apr 23, 2020, at 7:30 PM, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 24 Apr 2020, at 2:18, Rob Petrovec wrote:
>
>> I get a 1 second time for the first run and then a much quicker time for the
>> second. I did some sampling and the longer time due to is Apple’s check for
>> malware o
On 24 Apr 2020, at 2:18, Rob Petrovec wrote:
I get a 1 second time for the first run and then a much quicker time
for the second. I did some sampling and the longer time due to is
Apple’s check for malware on first run of a process. This is a
known, documented and advertised behavior.
I wo
>
> I believe that is why you are supposed to staple notarization tickets to your
> apps.
>
Then, why would it "phone home" in case there is an internet connection?
Best regards, Gabriel
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Ple
I believe that is why you are supposed to staple notarization tickets to your
apps.
Saagar Jha
> On Apr 23, 2020, at 12:12, Gabriel Zachmann via Cocoa-dev
> wrote:
>
>>
>> It appears the problem is not with a local service, but that Apple
>> actually ?phones home? when a program asks for di
> On Apr 23, 2020, at 9:10 AM, Allan Odgaard via Cocoa-dev
> wrote:
>
> On 23 Apr 2020, at 21:15, Rob Petrovec wrote:
>
>> If what you say is correct then everyone would be seeing a delay since most
>> people don’t have blazing fast internet connections. I do not think this is
>> the norma
>
> It appears the problem is not with a local service, but that Apple
> actually ?phones home? when a program asks for display name.
>
> I don?t know if this is common knowledge, but with notarization, Apple
> now validates executables on your system before they are executed, and
> it does so
On 23 Apr 2020, at 21:15, Rob Petrovec wrote:
If what you say is correct then everyone would be seeing a delay since
most people don’t have blazing fast internet connections. I do not
think this is the normal behavior.
Please try run this in a terminal and report the times:
rm -f /tmp/t
If what you say is correct then everyone would be seeing a delay since most
people don’t have blazing fast internet connections. I do not think this is
the normal behavior. I think it is specific to your system, otherwise there
would be TONS of people complaining about slowness. A couple seco
On 20 Apr 2020, at 0:11, Allan Odgaard via Cocoa-dev wrote:
Unfortunately though I can’t figure out *what* the problem is;
running `tccutil reset All` (and rebooting) did not fix it.
It appears the problem is not with a local service, but that Apple
actually “phones home” when a program asks
Regardless of whatever workaround you find, I would second Rob’s suggestion to
go ahead and file a bug with a sysdiagnose and/or spindump along with a sample
app that reproduces it. This isn’t expected behavior, and the teams at Apple
are still working and would be very interested in seeing thi
On 20 Apr 2020, at 0:37, Rob Petrovec wrote:
>> I think you are right about this being a permission / “sandbox”
issue, because the 3 folders in question are all folders that macOS
10.15 now require special permission to read (even though in my case,
I just request their display name).
Yes, th
>> I think you are right about this being a permission / “sandbox” issue,
>> because the 3 folders in question are all folders that macOS 10.15 now
>> require special permission to read (even though in my case, I just request
>> their display name).
Yes, this is because of iCloud. Log o
On 19 Apr 2020, at 22:54, David M. Cotter wrote:
i have discovered it may have to do with permissions / entitlements
that have been granted the app by the user, and that resetting all
perms to default will "fix" the problem
I think you are right about this being a permission / “sandbox”
issu
I assume you have iCloud enabled. If so, these three folders are ’special’.
Try logging out of iCloud & rebooting and see if the problem persists.
I would also recommend filing a bug with Apple and include a sysdiagnose taken
while the problem was reproducing (sudo sysdiagnose). Or at least a
this may be difficult for other to repro
i have discovered it may have to do with permissions / entitlements that have
been granted the app by the user, and that resetting all perms to default will
"fix" the problem
in the terminal, do this:
> tccutil reset All
i expect that after that, your de
On Dec 21, 2010, at 11:04 AM, Aki Inoue wrote:
> Note CoreText is a core layout engine, a building block for higher-level text
> engines such as AppKit. It doesn't necessarily perform better than
> higher-level engines which are caching by utilizing contextual info available.
Is there a defin
Yes, we optimized NSStringDrawing API since the documentation discouraging its
use was first written.
In fact, for some of short simple string rendering, it's the fastest on the
platform (use -drawWithRect:... variants for the maximum efficiency if
possible).
So, as already mentioned, use the
You could create an array of objects grouping the parameters of your strings
For example:
typedef struct
{
NSAttributedString*text; // it already contains color and font
NSPoint position;
} MyObj;
Or you can even create your own class MyObj
The you create the array
Hi Mike,
Seconding Sherm and Joar, this will be the easiest way to get started. Down the
line, if that doesn't work, have a look at Core Text.
Also, I have been developing an application for drawing with text. I draw a few
hundred individual letters at a time, then commit them to a graphics con
On Mon, Dec 20, 2010 at 11:53 PM, Joar Wingfors wrote:
>
> On 20 dec 2010, at 01.22, Mark Coniglio wrote:
>
>> My application needs to draw hundreds of short text strings into an NSView.
>> After reviewing the Cocoa documentation on drawing text, I am left unsure as
>> to how to do this with the
On 20 dec 2010, at 01.22, Mark Coniglio wrote:
> My application needs to draw hundreds of short text strings into an NSView.
> After reviewing the Cocoa documentation on drawing text, I am left unsure as
> to how to do this with the highest level of efficiency.
Don't optimize in the dark! Imp
On Fri, Aug 27, 2010 at 1:34 AM, Uli Kusterer
wrote:
> On 26.08.2010, at 20:37, Ken Thomases wrote:
>> Shark and most of the instruments in Instruments are statistical samplers,
>> not exact function-call measurement. Also, Vijay already mentioned
>> familiarity with Instruments.
>
> I am sorr
On 26.08.2010, at 20:37, Ken Thomases wrote:
> Shark and most of the instruments in Instruments are statistical samplers,
> not exact function-call measurement. Also, Vijay already mentioned
> familiarity with Instruments.
I am sorry, my mistake. I must have read "instruments tool" as somethin
On Aug 26, 2010, at 8:39 AM, Uli Kusterer wrote:
> On Aug 26, 2010, at 12:48 PM, Vijayakumar_Thota wrote:
>> I am working on the performance issues of an application. I am facing a
>> difficulty in finding out how many times a method is called in different
>> contexts.
>>
>> Suppose there is a
On Aug 26, 2010, at 12:48 PM, Vijayakumar_Thota wrote:
> I am working on the performance issues of an application. I am facing a
> difficulty in finding out how many times a method is called in different
> contexts.
>
> Suppose there is a method called 'setItem'. I need the report which tells
>
Am 16.11.2009 um 07:14 schrieb Chris Carson:
> The first class is the model that submits asynchronous bulk reads to the USB
> device. The callback for these reads copies the received data from the buffer
> asynchronous filled by the request and into an NSData object that is
> allocated and add
On Mon, Nov 16, 2009 at 1:14 AM, Chris Carson wrote:
> The application runs pretty well, and running it through the Leaks instrument
> there are no leaks except for 16-bytes when the application is first starting
> caused by IOUSBLib. However, looking at it in the Activity Monitor, the real
> m
On Sun, 15 Nov 2009 22:14:32 -0800 (PST), Chris Carson
said:
>The application runs pretty well, and running it through the Leaks instrument
there are no leaks except for 16-bytes when the application is first starting
caused by IOUSBLib. However, looking at it in the Activity Monitor, the real
mem
On 16 Nov 2009, at 06:14, Chris Carson wrote:
>
> The application runs pretty well, and running it through the Leaks instrument
> there are no leaks except for 16-bytes when the application is first starting
> caused by IOUSBLib. However, looking at it in the Activity Monitor, the real
> memo
On Oct 6, 2009, at 3:29 PM, Iceberg-Dev wrote:
The contents. It's a bit as if there was a patchwork of rectangles
and a random set of these rectangles would not be redrawn when the
window size increases by 1 pixel and then another set for the
following pixel.
That sounds like a graphics
On Oct 6, 2009, at 1:29 AM, Jens Alfke wrote:
On Oct 5, 2009, at 3:12 PM, Iceberg-Dev wrote:
Is it the intended behavior that resizing an Alert Sheet in Mac OS
X 10.5.8 on a MacBook Pro produces a lot of blinking?
I have a custom alert sheet that can be resized and when I resize
it on a M
On Oct 5, 2009, at 3:12 PM, Iceberg-Dev wrote:
Is it the intended behavior that resizing an Alert Sheet in Mac OS X
10.5.8 on a MacBook Pro produces a lot of blinking?
I have a custom alert sheet that can be resized and when I resize it
on a MacBook Pro (either 9400 or 9600 GPU), the resize
On Aug 26, 2009, at 4:20 AM, Naresh Kongara wrote:
I'm drawing the pages from the pdf document onto an NSVIew. The
fallowing method draws all the pages from the document in a View,
this method will be called from the view's drawrect. Its taking
much time when there are more than 40 pages a
Le 29 mai 09 à 11:31, Alexander Spohr a écrit :
Am 29.05.2009 um 02:55 schrieb John Ku:
And yeah, NSMutableString will be initialized else where and
released later.
Why use a mutable string at all? Just retain the new string and dump
the old one.
Use
@property (retain) NSString *title
Am 29.05.2009 um 02:55 schrieb John Ku:
And yeah, NSMutableString will be initialized else where and
released later.
Why use a mutable string at all? Just retain the new string and dump
the old one.
Use
@property (retain) NSString *title;
@synthesize title;
and be done with it.
On Thu, May 28, 2009 at 8:57 PM, Roland King wrote:
>>
>> So if i have:
>>
>> NSMutableString *title = [[NSString alloc] init];
>> [title setString: @"test"];
>>
>> That would be correct and safe?
>
> No. I hope it would emit warnings on compilation too.
No warning will be emitted. -init is decla
Better than making mistake one after another.
But good lesson for me.
Cheers,
John
On Thu, May 28, 2009 at 6:01 PM, Graham Cox wrote:
>
> On 29/05/2009, at 10:56 AM, Andrew Farmer wrote:
>
> Nope, that'd be assigning a NSString instance to a NSMutableString
>> variable
>>
>
>
> oops, missed t
On 29/05/2009, at 10:56 AM, Andrew Farmer wrote:
Nope, that'd be assigning a NSString instance to a NSMutableString
variable
oops, missed that ;-)
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests
So if i have:
NSMutableString *title = [[NSString alloc] init];
[title setString: @"test"];
That would be correct and safe?
Thank!!
John
No. I hope it would emit warnings on compilation too. That would set
title to an NSString instance, then you go calling setString: on it and
that's an
On 28 May 2009, at 17:48, Graham Cox wrote:
On 29/05/2009, at 10:42 AM, John Ku wrote:
NSMutableString *title = [[NSString alloc] init];
[title setString: @"test"];
That would be correct and safe?
Yes, but pointless.
Nope, that'd be assigning a NSString instance to a NSMutableString
varia
Yeah sorry everyone, in the original example i am using a constant.My
working app is actually using a mutable string. So I've got both mixed up.
And yeah, NSMutableString will be initialized else where and released later.
*hits myself in the head* Im not processing correctly today..
Thanks,
John
On Thu, May 28, 2009 at 5:42 PM, John Ku wrote:
> Thank you all for the explanation. After reading over and experiment, I kind
> of get what you all are saying.I've probably confused myself too much with
> the dot syntax to use title = @"fdsfd".
>
> So if i have:
>
> NSMutableString *title = [[NSS
On 29/05/2009, at 10:42 AM, John Ku wrote:
NSMutableString *title = [[NSString alloc] init];
[title setString: @"test"];
That would be correct and safe?
Yes, but pointless.
If the string is a constant, use a constant.
NSString* string = @"whatever";
--Graham
_
On Thu, May 28, 2009 at 4:57 PM, John Ku wrote:
> I have this original class with the following method:
> - (void) update {
> NSString *title = [[NSString alloc] init];
You create an empty string instance in the above and make title point at it.
> title = @"TEST";
You then make title point a th
Thank you all for the explanation. After reading over and experiment, I kind
of get what you all are saying.I've probably confused myself too much with
the dot syntax to use title = @"fdsfd".
So if i have:
NSMutableString *title = [[NSString alloc] init];
[title setString: @"test"];
That would b
On Thu, May 28, 2009 at 4:57 PM, John Ku wrote:
> NSString *title = [[NSString alloc] init];
> title = @"TEST";
NSString is immutable, and Objective-C doesn't have operator
overloading. So what you're doing here is creating an empty NSString,
assigning a pointer to it to your title variable, the
On 28 May 2009, at 16:57, John Ku wrote:
Is this a more efficient way to code? Which coding practice is
better in
terms of efficiency, memory, performance?
The update method will get called often. So Im thinking there is no
need to
create 'NSPoint drawAtOrigin' everytime.
Your thoughts?
N
On 29/05/2009, at 9:57 AM, John Ku wrote:
I have this original class with the following method:
- (void) update {
NSString *title = [[NSString alloc] init];
title = @"TEST";
This is incorrect for a start. You are leaking an empty string. You
allocate and initialise it, then reassign its poi
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
1 - 100 of 119 matches
Mail list logo
