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 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
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
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
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
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
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
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
> 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 25, 2014, at 5:42 PM, Roland King wrote:
> They can be very useful finding places where everything blocks waiting for
> one piece of code to execute, or you ping madly from thread-to-thread,
> queue-to-queue.
Thanks, that sounds very useful. I’lll give it a try when I dive back into t
Have you clicked the 'strategy' buttons at the top left of instruments, I for
some reason can only do this after I've recorded a trace, not during? They are
easily overlooked but show per-core or per-thread traces. They can be very
useful finding places where everything blocks waiting for one pi
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 expensive
> operation, because it will slow down all your dispatch_sy
On Apr 25, 2014, at 1:11 AM, Jonathan Taylor
wrote:
> Have you looked at the output from System Trace on both systems? I often find
> that to be informative.
OK, I tried this and it did turn out to be very informative :) even though I
don’t know how to interpret any of the numbers. But just
Have you looked at the output from System Trace on both systems? I often find
that to be informative.
That might or might not be the way to tell, but have you considered that the
very different CPU characteristics might mean that the actual timing and
pattern of database commands is different o
On Apr 24, 2014, at 22:49 , Jens Alfke wrote:
> It is, but most of it appears to be memory management _caused_ by GCD, since
> it goes away when I replace the dispatch calls with @synchronized. GCD is
> apparently causing a lot of blocks to get copied to the heap.
Well, you know what you’re se
On Apr 24, 2014, at 10:30 PM, Quincey Morris
wrote:
> Approaching this naively, this result suggests that the block content, while
> not trivial, is too fine-grained — is divided too finely. For example, if
> you’re putting (essentially) one database read/write operation (or even a
> handful
On Apr 24, 2014, at 20:14 , Jens Alfke wrote:
> On my MacBook Pro this gave me a nice speedup of 50% or more.
>
> But when I tested the code on my iPhone 5 today, I found performance had
> dropped by about a third.
> I know that dispatch queues aren’t free, but I wasn’t expecting them to be
>
Is there any way to batch up more work to do in each block? Then your ratio of
real work to overhead would go up.
On Apr 25, 2014, at 12:35 AM, Jens Alfke wrote:
>
> On Apr 24, 2014, at 9:04 PM, Dave Fernandes
> wrote:
>
>> What’s the CPU utilization? Are you actually getting full use of th
On Apr 24, 2014, at 9:04 PM, Dave Fernandes wrote:
> What’s the CPU utilization? Are you actually getting full use of them, or are
> your threads blocked waiting for something?
Fairly high — I think 175% or so (out of 200% possible). The problem is that a
large fraction of that is taken up wi
What’s the CPU utilization? Are you actually getting full use of them, or are
your threads blocked waiting for something?
On Apr 24, 2014, at 11:14 PM, Jens Alfke wrote:
> I’m writing an Objective-C API around a database library, and trying to add
> some optimizations. There’s a lot of room fo
On Apr 24, 2014, at 8:42 PM, Ken Thomases wrote:
> You may be aware of this, but dispatch_sync() is not necessary or even
> particularly relevant to thread-safety. The use of a serial queue or,
> possibly, a reader/write mechanism using barriers, is what achieves thread
> safety.
Initial ex
On Apr 24, 2014, at 10:14 PM, Jens Alfke wrote:
> I’m writing an Objective-C API around a database library, and trying to add
> some optimizations. There’s a lot of room for parallelizing, since tasks like
> indexing involve a combination of I/O-bound and CPU-bound operations. As a
> first step
Follow-up: I tried replacing every instance of
dispatch_sync(_queue, ^{ … });
with
@synchronized(self) { … }
Things got faster again — looks like @synchronized is a few percent slower than
no thread-safety, but _significantly_ faster than dispatch_sync. Which seems to
contradict
I’m writing an Objective-C API around a database library, and trying to add
some optimizations. There’s a lot of room for parallelizing, since tasks like
indexing involve a combination of I/O-bound and CPU-bound operations. As a
first step, I made my API thread-safe by creating a dispatch queue
24 matches
Mail list logo
