+1, there is no point in arguing with Knuth. On Mon, Aug 17, 2015 at 1:07 AM, Henry Saputra <henry.sapu...@gmail.com> wrote:
> +1 as well. > > This is a great follow-up from my previous email about adding details > in JIRA, which also being echoed by Fabian. > > - Henry > > On Sun, Aug 16, 2015 at 3:45 PM, Fabian Hueske <fhue...@gmail.com> wrote: > > +1 from me as well. > > > > I'd like to add that there are many relevant issues in listed in JIRA > that > > report bugs or describe interesting / important improvements of the > system. > > Working on one of these issues would be a great contribution to Flink. > > > > Cheers, Fabian > > > > 2015-08-16 18:30 GMT+02:00 Sachin Goel <sachingoel0...@gmail.com>: > > > >> I agree! > >> A good place to start would be to write an extensive JIRA guidelines > page, > >> an example would be > >> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark > . > >> This is quite crisp and clear. > >> Further, right now the corresponding guidelines for Flink are on the > cwiki > >> page, but the main README links to > >> http://flink.apache.org/how-to-contribute.html. We should perhaps merge > >> the > >> cwiki page content here. > >> > >> Regards > >> Sachin > >> > >> -- Sachin Goel > >> Computer Science, IIT Delhi > >> m. +91-9871457685 > >> > >> On Sun, Aug 16, 2015 at 9:21 PM, Stephan Ewen <se...@apache.org> wrote: > >> > >> > Hi all! > >> > > >> > Henry raised the point about non.descriptive bug reports earlier. I > would > >> > like to bring this to everyone's mind again and add some additional > >> > thoughts: > >> > > >> > We are seeing a lot of issues reported right now, and a lot of pull > >> > requests opened right now, for issues that are not really a problem. > >> > > >> > There are many places in the code, where one could write things > slightly > >> > different. Some of these slightly different variations may look > slightly > >> > more efficient at a first glance, but are not anywhere on a hot code > >> path, > >> > so they actually do not really make any difference. > >> > > >> > However, every of those changes introduces the possibility of new > bugs. > >> > Quite a few of the proposed fixes had actually changed the semantics, > >> with > >> > the result that they would have broken the system instead of improving > >> > anything. > >> > > >> > This has been famously summed up by Donald Knuth in his quote: > >> > > >> > "*Premature optimization is the root of all evil"* > >> > > >> > Before changing a line of code in the attempt to do one comparison > less, > >> > please check whether the change is actually worth it: > >> > > >> > - Better more checks than fewer checks, if the code path is not hot. > >> > Catching bugs better / earlier is worth a lot. > >> > > >> > - On modern processors, performance of non-I/O code is almost always > >> > limited by memory access delays (cache / TLB misses). Arithmetic and > >> checks > >> > are comparatively cheap, meaning that that optimizing it usually > matters > >> > only in arithmetic loops, or the hottest code paths. > >> > > >> > - Good fixes are still all fixes that address any form of resource > leak, > >> > or forgotten closing of streams, clients, ... > >> > > >> > - Performance critical in Flink's runtime are mainly the Serializer > >> code, > >> > the hash/sort algorithms, the network/disk code, the driver loops for > the > >> > operators. > >> > > >> > - On the JobManager, the number and dependencies of deployment > >> messages, > >> > and the complexity of the graph traversal dominate all other > computation. > >> > > >> > - Correctness and safety are always more critical than the last 1% of > >> > performance. > >> > > >> > > >> > This was my personal view on things, please write if you agree or > >> disagree. > >> > > >> > > >> > Greetings, > >> > Stephan > >> > > >> >
