On Mar 30, 2008, at 7:50 PM, Ben Lachman wrote:
I'm guessing the bugs really should be filed on the documentation
since one page on performance of a highly complex API like CD is
nowhere near enough. My guess is that documentation doesn't get as
many bugs as it should since it is, at the point of the developer
filing the bug, no longer a road block and therefore is kind of seen
(wrongly) as a waste of time since it is just for the greater good
of the dev community not getting your project done.
There are two sets of bugs you should file. (1) better documentation
for the current state of affairs and (2) better support for your work
pattern in a future version of the framework.
Developers need to file their own bugs.
There are several reasons for that. First, to be able to check the
status of an issue and track it over however long it takes to get
fixed. Second, to be accessible to ADC for follow ups, clarifications
in case we can't reproduce it, or receiving work arounds for known
issues. Especially since once in a while, you might actually get
back a work around that's better than what you came up with yourself.
Of course, filing the issue before spending lots of time developing a
workaround might also save you some effort once in a while.
And so my shadowy masters actually believe real live developers have
this problem, as opposed to my imaginary friends. Oddly "20
developers requested this" seems to work better than "we should spend
lots of time on this because I feel like it"
And that just covers the problems we already know about. There are a
few more reasons for filing bugs you've worked around ...
Thanks for the feedback it was quite helpful. Any thoughts or
tricks to reduce the frequency of saving in worker threads would be
welcome, but I think I'm now on the right path.
Batching and coalescing are both good ideas, so you're on the right
track. Your other alternative is a proxy object for inserts, as I
describe in one of the list archived messages I referenced earlier.
You could also consider evaluating whether or not requiring Leopard
makes sense for your customer base. At some point, there's a
diminishing return on your effort to address a problem that $130 can
mitigate. A compromise is to not perform the same threading on Tiger,
or not in the same way, and accept a somewhat different user
experience on older systems.
- Ben
_______________________________________________
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)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
