NSOperationQueue 调度线程缓慢？
我正在使用 NSOperationQueue 编写我的第一个多线程 iPhone 应用程序，因为我听说它比管理我自己的线程调度加载得更好，而且可能更快。
我正在计算生命游戏板的结果，方法是将板分成单独的部分，并让单独的线程计算每个板，然后将它们拼接在一起，对我来说，这似乎是一种更快的方法，即使分割和拼接的开销巨大。我正在为每个板创建一个 NSInitationOperation 对象，然后将它们发送到 OperationQueue。在我发送了所有的棋盘块后，我坐下来等待它们全部通过对操作队列的 waitUntilAllOperationsAreFinished 调用完成计算。
这看起来应该可以工作，而且确实工作得很好，但是线程被调用得非常慢，所以实际上多线程版本比单线程版本需要更长的时间来计算！哦，不！我监控了发送到 NSOperationQueue 的 NSOperations 的创建和终止，发现有些操作只是在操作队列中呆了一段时间，然后才被调用。起初我想“嘿，也许队列一次只能处理这么多线程”，然后将队列 maxConcurrentOperationCount 提高到某个任意高的数字（远高于棋盘的数量），但我也经历了同样的事情！
我想知道是否有人可以告诉我如何将 NSOperationQueue 踢入“超速”状态，以便它尽快调度其队列，或者告诉我发生了什么事！
I'm writing my first multithreaded iPhone apps using NSOperationQueue because I've heard it's loads better and potentially faster than managing my own thread dispatching.
I'm calculating the outcome of a Game of Life board by splitting the board into seperate pieces and having seperate threads calculate each board and then splicing them back together, to me this seems like a faster way even with the tremendous overhead of splitting and splicing. I'm creating a NSInvocationOperation object for each board and then sending them to the OperationQueue. After I've sent all the pieces of the board I sit and wait for them all to finish calculating with the waitUntilAllOperationsAreFinished call to the OperationQueue.
This seems like it should work, and it does it works just fine BUT the threads get called out very slooooowwwlllyyyyyy and so it actually ends up taking longer for the multithreaded version to calculate than the single threaded version! OH NOES! I monitored the creation and termination of the NSOperations sent to the NSOperationQueue and found that some just sit in the Operation Queue do-diddly-daddlin for awhile before they get called much later on. At first I thought "Hey maybe the queue can only process so many threads at a time" and then bumped the Queues maxConcurrentOperationCount up to some arbitrary high number (well above the amount of board-pieces) but I experienced the same thing!
I was wondering if maybe someone can tell me how to kick NSOperationQueue into "overdrive" so to say so that it dispatches its queues as quickly as possible, either that or tell me whats going on!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
线程并不会神奇地让你的处理器运行得更快。
在单处理器机器上，如果您的算法需要执行一百万条指令，那么将其分成 10 个块，每个块有 100,000 条指令并在 10 个线程上运行它仍然需要同样长的时间。实际上，它会花费更长的时间，因为您增加了线程之间的拆分、合并和上下文切换的开销。
Threads do not magically make your processor run faster.
On a single-processor machine, if your algorithm takes a million instructions to execute, splitting it up into 10 chunks of 100,000 instructions each and running it on 10 threads is still going to take just as long. Actually, it will take longer, because you've added the overhead of splitting, merging, and context switching among the threads.
队列从根本上仍然受到手机处理能力的限制。如果手机只能同时运行两个进程，那么通过拆分任务，您将（最多）接近两倍的速度提高。除此之外，您只是增加了开销而没有任何收益。
如果您正在运行处理器和内存密集型例程（例如板计算），则尤其如此。如果您有多个需要等待较长时间的操作，则 NSOperationQueue 很有意义。用户界面循环和网络下载就是很好的例子。在这些情况下，其他操作可以在非活动操作等待输入时完成。
对于像您的主板这样的东西，网格的每个部分的操作从来没有任何等待条件。它总是全速搅拌直到完成。
另请参阅：iPhone 最大线程限制？ 和 并发应用程序设计
The queue is still fundamentally limited by the processing power of the phone. If the phone can only run two processes simultaneously, you will get (at most) close to a two-fold increase in speed by splitting up the task. Anything more than that, and you are just adding overhead for no gain.
This is especially true if you are running a processor and memory intensive routine like your board calculation. NSOperationQueue makes sense if you have several operations that need to wait for extended periods of time. User interface loops and network downloads would be excellent examples. In those cases, other operations can complete while the inactive ones are waiting for input.
For something like your board, the operation for each piece of the grid never has any wait condition. It is always churning away at full speed until done.
See also: iPhone Maximum thread limit? and concurrency application design