> On Apr 23, 2018, at 1:30 AM, Alex Zavatone <z...@mac.com> wrote:
>
>
>> On Apr 22, 2018, at 11:22 PM, Rob Petrovec <petr...@mac.com> wrote:
>>
>>> VTDecodedXPCservice takes 147% of the processor cores on one of my boxes.
>> That is to be expected if you are playing any video or audio, and is
>> not new to High Sierra. There are tons of reports online about it taking
>> alot of CPU.
>>
>>
>> I am not hitting these issues and I use APFS on all my partitions. I don’t
>> have any third party system mods installed on my machine. Maybe its not the
>> file system, but some app you have installed that is effecting the OS?
>> Wouldn’t be the first time that has happened.
>
> I’ve got 5 Macs. These errors are common across many of them.
>
>>
>> Have any of you filed bug reports about the issues you are seeing, including
>> but not limited to a sysdiagnose,
>
> No, because historically, all the time I have spent on reporting issues has
> been an utter waste of my time.
For the most part, I have had the opposite experience over the years.
Typically, the bugs either gets duped to one they already have, or they ask for
additional information which I provide. Sometimes the bug sits for a while,
but they all have gotten resolved one way or another. From talking to some
Apple Engineers at WWDC over the years, the bar to get a bug fixed in a
software update is pretty high. They would rather allow a bug to continue to
exist then possibly introduce a regression. Its the devil you know vs the
devil you don’t kind of thing with a serious risk vs reward evaluation. It is
much easier for them to get a fix into a major release (e.g. 10.13(.0)), so the
wait to see a fix is typically over a year.
If you report it and they don’t fix it after a major release, then you
have all the right in the world to complain. However, if you don’t report it,
IMO, you don’t have any right to complain.
> Recently I reported a text failure in Mail, added instructions and a sample
> to reproduce it. They reported it fixed. I spent my time to check on the
> latest Mac OS and it’s not fixed. I marked the bug as Still Open As Written.
> Nothing’s been done about it since. My time has been triply wasted as a
> result.
How long ago did you mark it SOAW? No offense but if there hasn't been
a full OS release cycle since then I think you may be a little overly critical,
cynical and impatient. As I said above, getting a bug into a software update
is very difficult. The reward has to be significantly higher then the risk.
So maybe it will get fixed in the next major release or they are having trouble
reproducing or something benign like that?
> I don’t have time to professionally do Apple’s job for them and they aren’t
> paying me to.
I agree. However, you also can’t expect Apple to be able to test all
possible configurations or scenarios. That would be physically & statistically
impossible. That is one reason they have the beta program, to get a wider
audience before the public release. Without (well written) bug reports from
devs, they may never know about issues like this. Especially since issues like
this are highly configuration dependent.
> Maybe one issue has been fixed, but the point is that our time is wasted when
> something fails. We have to spend more of our time to find a workaround. I
> don’t have time to do that, report their bugs with no guarantee that it may
> get addressed.
So by that logic, you are saying that in the products you work on,
every single issue reported by users is addressed & fixed in a timely manor?
If not, with your relatively small app compared to their huge OS, how could you
expect Apple too? If you can’t guarantee that every single user issue is fixed
in your products how could you possibly expect Apple? Seriously.
—Rob
>> spindump, Instruments System Trace taken _while_ the slowness was occurring.
>> If your issue is related to being connected to an SMB share, you should
>> include info about the server you are connecting to (e.g. OS on the Server,
>> WiFi or Ethernet, large or small network etc etc)? If your issue is I/O
>> bound, then an lsof run taken during the slow I/O session is also useful.
>> Without that kind of info there isn’t any way they can possibly fix it.
>> Just sayin’… Maybe reply to this thread with the bug numbers you’ve filed
>> in case an Apple Engineer sees this thread.
>>
>> —Rob
>
>
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
