flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Till Rohrmann <trohrm...@apache.org>
Subject Re: [NOTICE] Reporting and fixing minor issues
Date Tue, 18 Aug 2015 08:43:49 GMT
+1, there is no point in arguing with Knuth.

On Mon, Aug 17, 2015 at 1:07 AM, Henry Saputra <henry.saputra@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 <fhueske@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 <sachingoel0101@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 <sewen@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
> >> >
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message