Artyom, PostgreSQL started timing out or taking a VERY long time. We have a Bulidbot that builds several projects and none of them were timing out before this commit. I don't know the specific revision; but it is PostgreSQL 9.1.
I suggest reverting this commit and investigating why it causes the regression. Generally, we should come up with a solution that does not take hours on any of the benchmarks. Anna. Sent from my iPhone > On Sep 20, 2014, at 8:10 AM, Artyom Skrobov <[email protected]> wrote: > > Anna, do you mean the performance had been acceptable after r214064, but > degraded after r215650, which fixed the performance regression introduced in > r214064? > > Do you have any specific example of code that takes longer to compile after > r215650? > > Not hearing back from Alexander since August, I assumed the performance > regression he observed after r215650 was not in fact related to that commit. > > I suspect it is related. > From: Anna Zaks [mailto:[email protected]] > Sent: 20 September 2014 01:19 > To: Artyom Skrobov > Cc: [email protected] Commits; Ted Kremenek; Jordan Rose; Alexander > Kornienko > Subject: Re: [PATCH] Inverse post-order traversal for LiveVariables analysis, > to recover the performance after r214064 > > Hi Artyom, > > Unfortunately, this commit (r215650) causes major performance regressions on > our buildbots. In particular, building postgresql-9.1 times out. > > Please, revert as soon as possible. > > Thank you, > Anna. > On Aug 20, 2014, at 3:13 AM, Alexander Kornienko <[email protected]> wrote: > > On Fri, Aug 15, 2014 at 10:38 AM, Artyom Skrobov <[email protected]> > wrote: > Many thanks -- committed as r215650 > > Alexander, can you confirm that the analyzer performance is now acceptable > for your use cases? > > Artyom, sorry for the long delay. These files now work fine, but I still see > up to 8-10 hours analysis time on a couple of other files. I'm sure I didn't > see this before your first patch, but I can't yet tell in which revision it > was introduced. I'll post more details and a repro later today. > > > > -----Original Message----- > From: Ted kremenek [mailto:[email protected]] > Sent: 14 August 2014 16:36 > To: Artyom Skrobov > Cc: Alexander Kornienko; [email protected] > Subject: Re: [PATCH] Inverse post-order traversal for LiveVariables > analysis, to recover the performance after r214064 > > Looks great to me. > > > On Aug 14, 2014, at 3:08 AM, Artyom Skrobov <[email protected]> > wrote: > > > > Thank you Ted! > > > > Attaching the updated patch for a final review. > > > > Summary of changes: > > > > * Comments updated to reflect the two possible CFG traversal orders > > * PostOrderCFGView::po_iterator taken out of the header file > > * Iteration order for PostOrderCFGView changed to "reverse inverse > > post-order", the one required for a backward analysis > > * ReversePostOrderCFGView created, with the same iteration order that > > PostOrderCFGView used to have, the one required for a forward analysis > > * The two previous consumers of PostOrderCFGView, ThreadSafetyCommon.h and > > Consumed.cpp, switched to use ReversePostOrderCFGView > > * DataflowWorklistBase renamed to DataflowWorklist, and the two > > specializations named BackwardDataflowWorklist and ForwardDataflowWorklist > > > > I believe this naming scheme matches the accepted terminology best. > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
