Hacker News Reader

Comment by mr_justin | Hacker News Reader

Really? I leave mine running for weeks on end with no issues. I try to keep it up to date but usually let the updates stew for a month before upgrading. iTunes is indispensable software for me, and I don't own an iPhone, iPad, iPod or any of that. Nor do I use it for purchasing music. Strictly as a music organizer/player, I think it is fantastic and integrates perfectly with the operating system.

That being said, the last time I used iTunes on Windows it was about as enjoybable as waiting for a Java Applet to load up.

View on HN

I don't mean it crashes. I just hate how unresponsive it is.

It gives me the beachball anytime I do anything involving I/O (syncing, adding songs, retrieving album art, calculating gapless bullshit). That's bad UI programming. Do your I/O in a background thread.

I know it's doing it on the GUI thread because I'll command-tab to it and it won't redraw, which of course prevents me from cancelling out of whatever task-I-didn't-ask-for it's doing.

This, btw, is the same behaviour I hated on windows.

Out of curiosity, is your library on an external disk that sleeps? Mine was, and it seemed to hang while waiting for the disk to spin up. I moved it to an always on disk, and the hangs stopped.

I was just counting seconds the other day (iTunes, modern x86 mac, 40k songs or so)

  Managing iPhone, changing tabs, 5 seconds of beachball.
  Go to iTunes store, 23 seconds of frozen app.
  Trying to see if I have new podcasts while downloading music: 12 seconds of beachball.

If you EVER see a beachball on a Mac then either your hardware is failing or your application's programmer has failed. Your programmer should NEVER do an operation that can block and make the user interface unresponsive in the user interface thread. Ever.

Beachball aside, why does it take 100 billion cpu clock cycles to switch from one tab to another?

Beachball aside, why does it take 100 billion cpu clock cycles to switch from one tab to another?

Because 90% of those cycles are spent in other processes while your kernel is waiting for your blocking I/O to finish, and 5% or more of the rest are taken by the kernel to let other tasks run. </pedantic>

Reply on news.ycombinator.com