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
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];
#if __LP64__
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.
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
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?HowToCreateTollFreeBridgedClass
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
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 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 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 would appear to
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
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
sort
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
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 a pretty big hit on
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 tell
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 on user
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, given
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 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 when
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.
begin excerpt
[...]
The collector runs exclusively on
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
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
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
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
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 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, if you
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
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
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
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
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:
30 matches
Mail list logo
