On Sun, Jul 13, 2008 at 12:29 PM, Marcel Weiher <[EMAIL PROTECTED]> wrote:
>
> On Jul 12, 2008, at 13:42 , Michael Ash wrote:
>
http://www.opensource.apple.com/darwinsource/projects/apsl/CF-476.10/CFRuntime.h
>>
>> typedef struct __CFRuntimeBase {
>> uintptr_t _cfisa;
>> uint8_t _cfinfo[4];
>>
On Jul 12, 2008, at 13:42 , Michael Ash wrote:
http://www.opensource.apple.com/darwinsource/projects/apsl/CF-476.10/CFRuntime.h
typedef struct __CFRuntimeBase {
uintptr_t _cfisa;
uint8_t _cfinfo[4];
#if __LP64__
uint32_t _rc;
#endif
} CFRuntimeBase;
I guess this isn't the right one,
It looks like it was expanded in 10.5, then, but 10.4 and prior use the
16-bit variables. Regardless of whether it handles overflows or not, my
little joke was meant to illustrate that too many developers (generally
speaking) think that resources (generally speaking) are unlimited and
put no t
On Sat, Jul 12, 2008 at 1:24 PM, Marcel Weiher <[EMAIL PROTECTED]> wrote:
> No, the inline reference count is available for all CF objects, and not
> limited to 64 bit.
> What version of the structure are you looking at? For example
> http://www.cocoadev.com/index.pl?HowToCreateTollFreeBridgedCla
Marcel Weiher wrote:
uint16_t _rc;
Oh, the horror of it all! Only 65,535 objects can retain a string!!!
What am I to do when I model all the citizens of the US voting for just
one presidential candidate in November, and the retain count overflows?!?!
Okay, that's not a real concern fo
On Jul 12, 2008, at 8:25 AM, Michael Ash wrote:
On Sat, Jul 12, 2008 at 2:25 AM, Marcel Weiher <[EMAIL PROTECTED]
> wrote:
So as I said: (a) object allocation slowest (b) out-of-band
retain count
slow (c) inline retain count much faster than either.
Well that all makes sense, thanks.
On Sat, Jul 12, 2008 at 2:25 AM, Marcel Weiher <[EMAIL PROTECTED]> wrote:
>
> On Jul 11, 2008, at 12:53 , Michael Ash wrote:
>
>>
>> Seems that NSString and NSMutableString are just faster at everything.
>> In all cases, the cost of an extra retain/release for them is still
>> roughly 50% of the co
On Jul 11, 2008, at 12:53 , Michael Ash wrote:
Seems that NSString and NSMutableString are just faster at everything.
In all cases, the cost of an extra retain/release for them is still
roughly 50% of the cost of an alloc/init/retain. Here are my raw
numbers, times in nanoseconds:
[timings sn
On 7/7/08 11:25 PM, Hamish Allan said:
>On Mon, Jul 7, 2008 at 6:33 PM, Sean McBride <[EMAIL PROTECTED]> wrote:
>
>> There's always the lower-level:
>>
>>objc_collect (OBJC_EXHAUSTIVE_COLLECTION |
>>OBJC_WAIT_UNTIL_DONE);
>
>If this were called from the main thread, would it guarantee
On Fri, Jul 11, 2008 at 2:17 PM, Marcel Weiher <[EMAIL PROTECTED]> wrote:
>
> On Jul 11, 2008, at 8:59 , Michael Ash wrote:
>
>>> The cost of a single refcounting op is negligible compared to the cost of
>>> object allocation, so these two are quite irrelevant.
>>
>> A quick test of this claim woul
On Jul 11, 2008, at 8:59 , Michael Ash wrote:
The cost of a single refcounting op is negligible compared to the
cost of
object allocation, so these two are quite irrelevant.
A quick test of this claim would appear to disprove it. On my Mac Pro,
an alloc/init/release cycle of NSObject costs
On Fri, Jul 11, 2008 at 3:21 AM, Marcel Weiher <[EMAIL PROTECTED]> wrote:
>> [not referring to scanning overhead]
>>
>> - Temporary objects get a 'release' at the end of their life, and
>> usually an 'autorelease' at the beginning.
>
> The cost of a single refcounting op is negligible compared to t
There are several ways to share the implementation:
1. Do nothing, CF and Foundation already do it for most of their
objects
(and they share their implementation...probably
unreasonably...)
This, obviously, doesn't work for your own classes.
But a lot of the objects you will use
On Thu, Jul 10, 2008 at 7:33 PM, Marcel Weiher <[EMAIL PROTECTED]> wrote:
>
> On Jul 10, 2008, at 9:50 , Michael Ash wrote:
>
>> On Thu, Jul 10, 2008 at 12:17 PM, Marcel Weiher <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> [hash tables not generally used + internal refcounts]
>
>> Atomic updates are still
On Jul 10, 2008, at 9:50 , Michael Ash wrote:
On Thu, Jul 10, 2008 at 12:17 PM, Marcel Weiher <[EMAIL PROTECTED]
> wrote:
[hash tables not generally used + internal refcounts]
Atomic updates are still a pretty big hit on a multiprocessor system
(all of them, these days),
Yes, they're defi
On Thu, Jul 10, 2008 at 12:17 PM, Marcel Weiher <[EMAIL PROTECTED]> wrote:
> Some minor factual corrections:
>
>
> On Jul 2, 2008, at 18:33 , Michael Ash wrote:
>
>> In Cocoa you do lots of retaining and releasing. These operations
>> aren't free. They involve a lookup into a global hash table and
Some minor factual corrections:
On Jul 2, 2008, at 18:33 , Michael Ash wrote:
In Cocoa you do lots of retaining and releasing. These operations
aren't free. They involve a lookup into a global hash table and some
sort of atomic increment/decrement operation.
The hash table is only used by NS
On Mon, Jul 7, 2008 at 6:33 PM, Sean McBride <[EMAIL PROTECTED]> wrote:
> There's always the lower-level:
>
>objc_collect (OBJC_EXHAUSTIVE_COLLECTION |
>OBJC_WAIT_UNTIL_DONE);
If this were called from the main thread, would it guarantee that the
collector run without interruption, giv
On 7/6/08 11:18 PM, Hamish Allan said:
>
>collectExhaustively
>Tells the receiver to collect iteratively.
>
>- (void)collectExhaustively
>
>Discussion
>You use this method to indicate to the collector that it should
>perform an exhaustive collection. Collection is subject to
>interruption
El 07/07/2008, a las 0:18, Hamish Allan escribió:
On 7/4/08, Chris Hanson <[EMAIL PROTECTED]> wrote:
Under non-GC, an object's memory may not be reclaimed until the
current
autorelease pool is drained. However, under GC, an object's memory
can be
reclaimed as soon as the collector can tel
On 7/4/08, Chris Hanson <[EMAIL PROTECTED]> wrote:
> Under non-GC, an object's memory may not be reclaimed until the current
> autorelease pool is drained. However, under GC, an object's memory can be
> reclaimed as soon as the collector can tell there are no more references to
> it -- no matter
El 06/07/2008, a las 2:05, mmalc crawford escribió:
On Jul 5, 2008, at 3:00 PM, Joan Lluch (casa) wrote:
However, let me copy an excerpt of the Cocoa documentation on the
GC algorithm that Cocoa uses.
You haven't updated your documentation since the beginning of
November last year.
On Jul 5, 2008, at 3:00 PM, Joan Lluch (casa) wrote:
Basically for performance reasons, the G. collector "preffers" to
let memory usage grow (while it is still available) in order to
avoid too many collections or to try that the user does not notice
it, and in practice it generally succeeds
On Jul 5, 2008, at 3:00 PM, Joan Lluch (casa) wrote:
However, let me copy an excerpt of the Cocoa documentation on the GC
algorithm that Cocoa uses.
You haven't updated your documentation since the beginning of November
last year.
[...]
The collector runs exclusively on the main threa
El 04/07/2008, a las 22:54, Chris Hanson escribió:
On Jul 4, 2008, at 2:25 AM, Joan Lluch (casa) wrote:
First, GC makes programs go slower not because of the overhead of
the garbage collection itself, which I concede that may be
comparable to the retain/release calls in a non-managed
env
On Jul 4, 2008, at 9:32 AM, Joan Lluch (casa) wrote:
However, this is hardly possible with GC even if you trigger the GC
manually in the middle of the loop. It simply will not release the
memory at the rate you expect because it follows its own rules and
as far as free memory is available i
On Jul 4, 2008, at 2:25 AM, Joan Lluch (casa) wrote:
First, GC makes programs go slower not because of the overhead of
the garbage collection itself, which I concede that may be
comparable to the retain/release calls in a non-managed environment,
but for the extra memory overhead that it is
El 04/07/2008, a las 11:38, Jean-Daniel Dupas escribió:
I don't see your point.
Using standard memory management, you can create you own pool, and
using GC, you can manually trigger the GC. What prevent you to avoid
memory peak ?
Bonjour, Jean.
Try it yourself. With the correct use of a
Le 4 juil. 08 à 11:25, Joan Lluch (casa) a écrit :
There is a couple of points I think you are missing here.
First, GC makes programs go slower not because of the overhead of
the garbage collection itself, which I concede that may be
comparable to the retain/release calls in a non-manag
El 03/07/2008, a las 3:33, Michael Ash escribió:
On Wed, Jul 2, 2008 at 6:09 PM, Joan Lluch (casa) <[EMAIL PROTECTED]>
wrote:
Basically, all you have to do is to always return autoreleased
objects from
your methods, and always send release to objects that you created
with alloc
or were ret
On Wed, Jul 2, 2008 at 6:09 PM, Joan Lluch (casa) <[EMAIL PROTECTED]> wrote:
> Basically, all you have to do is to always return autoreleased objects from
> your methods, and always send release to objects that you created with alloc
> or were returned by any method containing "new" or "copy". Also
El 30/06/2008, a las 19:33, [EMAIL PROTECTED] escribió:
hey,
I have a project that uses Bonjour for some of its communication,
theres a server and a client, and I was having tremendous difficulty
getting it to work, pouring and pouring over my code, only to
discover some weeks later that
On Mon, Jun 30, 2008 at 9:10 PM, eblu <[EMAIL PROTECTED]> wrote:
>hostname = [sender hostName];
>socket = (NSSocketPort*)[[NSSocketPortNameServer sharedInstance]
> portForName:@"BKOtherPort" host:hostname];
>connection = [NSConnection connectionWithReceivePort: nil sendPort
Le 30 juin 08 à 22:19, Jean-Daniel Dupas a écrit :
Le 30 juin 08 à 22:10, eblu a écrit :
Hi Chris,
I'm not terribly sure what you are asking for here. From my
experience (limited experience admittedly) theres really only one
way to use NSConnection.
its a pretty elegant class, which is s
Le 30 juin 08 à 22:10, eblu a écrit :
Hi Chris,
I'm not terribly sure what you are asking for here. From my
experience (limited experience admittedly) theres really only one
way to use NSConnection.
its a pretty elegant class, which is simple, and works as expected,
except for when garbag
Hi Chris,
I'm not terribly sure what you are asking for here. From my
experience (limited experience admittedly) theres really only one way
to use NSConnection.
its a pretty elegant class, which is simple, and works as expected,
except for when garbage collection is enabled.
heres what I
Hi there-
I encountered the same issue some months ago, and posted my questions
to this list. An Apple engineer did reply off-list that this was a
known issue with garbage collection and that there was no known
workaround at that time.
I was just playing with GC for fun and reverted back
hey,
I have a project that uses Bonjour for some of its communication,
theres a server and a client, and I was having tremendous difficulty
getting it to work, pouring and pouring over my code, only to discover
some weeks later that for some odd reason, NSConnections do not work
when the p
38 matches
Mail list logo
