On Fri, 24 Apr 2015 10:50:11 -0700 Rob Miller <rmil...@mozilla.com> wrote:
> My current thinking is that we'll let both of the APIs exist side by side for > a while. This would mean existing plugins could support buffering, albeit > with a performance hit, with only trivial code changes. Much improved > performance would be possible, but it would require reimplementing the plugin > using the newer API. I like this idea. You/heka dev team might be way ahead of me but my experience with refactoring code and changing this kind of stuff (goroutines, channels, function calls,..) is that unexpected performance issues can appear after weeks/months of use. Especially channel performance can be unexpected and dependent on implementation (isn't there a new channel implementation coming in go 1.5 or 1.6?). So I think it's good that you support both api's (if that's doable without too much work) and then let people adopt it and try it out as they see fit until we're reasonable confident there's no more hidden traps, and only then start major mind numbing refactoring work that is hard to reverse. It certainly can be a tricky balance (high performance vs generic, flexible mechanisms), I would personally be curious to read more about what the cost is that each feature brings to the table. Especially where synchronization/channels are used. anyway, looks like great work as always, heka team! _______________________________________________ Heka mailing list Heka@mozilla.org https://mail.mozilla.org/listinfo/heka
