flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kostas Tzoumas <ktzou...@apache.org>
Subject Re: [NOTICE] Reporting and fixing minor issues
Date Tue, 18 Aug 2015 10:26:00 GMT
big +1

On Tue, Aug 18, 2015 at 10:43 AM, Till Rohrmann <trohrmann@apache.org>
wrote:

> +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