Re: ptrlist-iterator performance on one wine source file

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Sun, Jul 30, 2017 at 06:16:03PM +0200, Luc Van Oostenryck wrote:
> On Sun, Jul 30, 2017 at 5:49 PM, Christopher Li <sparse@chrisli.org> wrote:
> 
> >>> >> In the memops finding dominating store is doing a lot worse. That is
> >>> >> why gcc complete that file almost instantly. Sparse takes 30 seconds
> >>> >> on my machine. One big problem is it did not cache the dominating
> >>> >> result. It is redoing the finding again and again.
> >>>
> >>> > Uh?
> >>> > Which input file your talking about?
> >>>
> >>> This ptrlist testing wine source file that takes  23 second for sparse to run.
> >>> I take a brief look at it, it is doing a lot of dominating search.
> >>
> >> Is it possible to have a pathname or a link?
> >
> > It is the very first email I send out:
> >
> >
> > git clone git://source.winehq.org/git/wine.git
> > cd win/dlls/usp10/tests
> >
> > The test command:
> >
> > time sparse -m64 -c -o usp10.o usp10.c -I. -I../../../include
> > -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
> > -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers
> > -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits
> > -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith
> > -Wlogical-op -gdwarf-2 -gstrict-dwarf -g -O2
> 
> OK, thanks. I'll take a look once the infinite loop problem will be closed.
> 
> > I think gcc compile this file very fast but sparse spend a lot of time on it.
> 
> Interesting.
> On most input sparse is much faster than gcc, often by a factor or 10
> or even more. But of course, if there is a problem with sparse ...
> 
> > My impression it is spending time repeat finding dominating stores.
> Possible indeed.

When I try the command you gave with -rc4 sparse I get:
	real	0m3.281s
	user	0m3.175s
	sys	0m0.097s
wich is very far from the 23-30s you got. Dunno what the difference could be.

For comparison, with the new 7 patches the time is now:
	real	0m2.146s
	user	0m1.928s
	sys	0m0.214s
wich is significatively faster.

And with gcc I get:
	real	0m2.153s
	user	0m2.080s
	sys	0m0.078s

Also, the result of the preprocessing is a 13K lines, 788K bytes file.

I would still expect that sparse is (much) faster than gcc, but
with the number I have here, I'm not sure I can say something is wrong.
But we should first find why you got 23-30s while I got 3.3.

-- Luc