According to the data from a reddit thread (https://www.reddit.com/r/feedthebeast/comments/3kx5y8/smp_agricraft_irrigation_channels_are_cpu/) the implementation is moderately inefficient.

From a quick look it can be optimized by caching the neighbors by only updating them every 1024 ticks, when a neighbor update is received and on the very first tick/load. The fluid level calculation and network update may benefit from some hysteresis to avoid what's effectively rounding errors to trigger more expensive operations.

Caching is a good idea, but why would I have to update every 1024 ticks? Isn't on neighbour update and load enough?
And I don't really understand what you mean by hysteresis.

It's essentially just a slow fixup for the odd case where a neighbor notification is missing. The notifications aren't strictly enforced, e.g. a mod could call setBlock without the associated flag bit (1?). If you can ensure it always happens or you consider it unimportant, the period check can be scrapped of course.

With hysteresis I'm referring to adding a suitable threshold from the previously processed state to start processing. I don't know what exactly your calculation is doing, but I'd require the neighbor channel to have at least a few mB more before updating. Likewise network syncs can be delayed until the rendered level change is large enough to be recognized.

I see, didn't think of that. I've added the discrete level check back in as well to reduce network usage.