launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Julian Edwards wrote:
> On Thursday 08 October 2009 22:21:20 Aaron Bentley wrote:
>> I don't think so.  It's no coincidence that Muharem presented a Job
>> system as a use case at the Epic.  Polling will never be as responsive
>> or efficient as messaging.
> 
> I disagree with the word "never".

> Consider the situation where you have several updates causing diff requests on 
> the same branch.  You're only interested in the last change; with a message 
> for each diff request, calculating the diffs in-between is a waste as you will 
> throw them away with subsequent diff processing.  If you were to periodically 
> poll, you would see only the most recent change and work with that.
> 
> This is a slightly contrived example but you get my drift.

I do get your drift, but I feel like you're not getting mine.  In your
example, the efficiency gain comes from doing different work in the
polling solution than the messaging solution would do.

I can restate it as "Polling will never be as responsive or efficient as
messaging *for doing the same work*?", but I thought that was implied.

We can revise a messaging-based system to have the same efficiency gain
by introducing a deliberate delay between the receipt of the message and
the diff generation, and then discarding any duplicate requests.

This will actually be more efficient than a polling-based solution.
Let's say we're polling every minute.  Suppose 3 updates come in 5
seconds apart, at 00:00, 00:05, and 00:10.  If the poll happens any time
between 0 and 10, an unnecessary diff will be performed.  This is a
one-in-6 chance, so it's quite plausible.

Now let's look at a messaging system with a 30-second delay, the same as
the average delay of the polling system.  Given the same updates at
00:00, 00:05, and 00:10, it will never generate an unnecessary diff.

If we want to make the polling system more efficient, we need to
increase the delay between polls.  But increasing the delay only reduces
the likelihood of unnecessary work, not eliminating it.  As the delay
approaches infinity, the efficiency approaches the efficiency of the
messaging system.

If we want to increase the responsiveness, we need to reduce the delay.
   We can achieve a worst-time responsiveness equivalent to the
messaging system by halving the delay to 30 seconds, but this doubles
the likelihood of unnecessary work to one-in-three.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrPUdAACgkQ0F+nu1YWqI2kbQCeOHtcWEzW+zSL26EZe7S+aLAZ
1D0An3DZdnVvG6tB4vaYVwRSMjE4ugfe
=VMoj
-----END PGP SIGNATURE-----