big +1 On Tue, Aug 18, 2015 at 10:43 AM, Till Rohrmann <trohrm...@apache.org> wrote:
> +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 > > >> > > > >> > > >
