Official Google Mac Blog: Measuring performance of distributed notifications on the performance of Google Update: "Just how expensive is it? How many notifications can you broadcast per second? As with all Google client products, we want to be good citizens and not bog down the client machine."
A noble sentiment, but dear Google, answer me this: just how many times per second is each app going to be checking for updates? When does this become an important factor, and not a question of premature optimisation? They decided to go for distributed notifications instead of distributed objects, which seems reasonable - not because of the overhead issues (in fact a DO is probably a lot cheaper, if written properly), but because of the kind of information they're trying to get through this IPC.
3 comments:
Each client isn't polling for updates - it's blocking (or doing its own thing and visiting the runloop when needed) until one comes it, so no need to worry about each app checking X times a second.
We were mainly concerned with Apple's note in the documentation about possible performance problems (which may have been an issue in the old NeXTstep days, a couple of moore's law generations ago), and to convince ourselve that for our usage, it won't be a pain point on the user's machine. So more like making the go/no-go decision, vs premature optimization.
DO is probably lower overhead, but it's harder to program reliably - like being robust in the face of communications problems vs just registering yourself as a distributed notification observer
Thanks for the comment! Good to keep us on our toes.
Cool, thanks Mark for your reply. My "how many times a second" question was flippant, but I was [you hope - Ed.] making the point that these notifications probably aren't going to stop any of the apps from having time to get their real work done, and besides you can always write the code first, and see how well it performs once it's written ;-).
I suppose you're right about the NeXTSTEP derivation of the performance concerns - a distributed note has to be copied to each process (presumably, what really happens is that a mach_vm page is just mapped into each of their address spaces), which then has to decide whether or not it cares about the notification - whereas other IPC mechanisms must be mutually agreed by the two processes so the scaling with number of other apps running is O(1).
BTW, this all makes me wonder how OpenStep for Solaris and OpenStep Enterprise handled distributed notes - perhaps in a similar way to GNUstep with gdnc? Got a spare SPARC box I could borrow? :-D
heh. Last Solaris box I used was server systems back in 2000, alas. If I had one, though, it'd be yours :-)
Post a Comment