Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: slow compilation on generated code #17127

Closed
mschoch opened this issue Sep 15, 2016 · 8 comments
Closed

cmd/compile: slow compilation on generated code #17127

mschoch opened this issue Sep 15, 2016 · 8 comments
Milestone

Comments

@mschoch
Copy link

mschoch commented Sep 15, 2016

What version of Go are you using (go version)?

$ go version
go version go1.7 darwin/amd64

What operating system and processor architecture are you using (go env)?

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/mschoch/go"
GORACE=""
GOROOT="/Users/mschoch/Documents/research/gosrc"
GOTOOLDIR="/Users/mschoch/Documents/research/gosrc/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?

$ mkdir /tmp/gp
$ export GOPATH=/tmp/gp
$ go get -tags 'prod' github.com/blevesearch/segment

What did you expect to see?

Under 1.6 this runs for several seconds, but compiles successfully in somewhat reasonable time. It was always slow (due to very large generated source files which is why we protect this version behind the 'prod' build tag).

What did you see instead?

At this point it appears to hang for minutes. Running top shows:

PID    COMMAND      %CPU TIME     #TH   #WQ  #PORT MEM    PURG   CMPRS  PGRP  PPID  STATE    BOOSTS         %CPU_ME %CPU_OTHRS UID  FAULTS    COW    MSGSENT   MSGRECV   SYSBSD    SYSMACH   CSW        PAGEINS IDLEW    POWE USER
48037  compile      96.7 18:16.05 5/1   0    17    623M   0B     0B     48033 48033 running  *0[1]          0.00000 0.00000    501  160783    23     78        6         109603+   568       2165690+   10      129      96.7 mschoc

I have given it at least 10 minutes now.

Additional Info

This repo contains Go source generated by the Ragel state machine compiler. The file in question segment_words_prod.go is 2.57 MB. Direct link to this file: https://raw.githubusercontent.com/blevesearch/segment/master/segment_words_prod.go
This particular version was generated with the -G2 flags which. The version produced for use without the prod build tag uses-F1 continues to work fine in 1.7.

@bradfitz
Copy link
Contributor

I believe this is a dup of another SSA regression or so, but I forget which ones.

Can you try Go tip?

/cc @dr2chase @randall77

@bradfitz bradfitz changed the title Go compiler appears to hang while compiling segment library with prod build tag cmd/compile: slow compilation on generated code Sep 15, 2016
@bradfitz bradfitz added this to the Go1.8 milestone Sep 15, 2016
@mschoch
Copy link
Author

mschoch commented Sep 15, 2016

I tried again with tip:

$ go version
go version devel +22d3bf1 Thu Sep 15 19:24:04 2016 +0000 darwin/amd64

Still compiling after 10 minutes.

Looks like it may be duplicate of #16407

@bradfitz
Copy link
Contributor

Yeah, let's merge this into #16407. Please comment on that bug with a link to your code.

ns-codereview pushed a commit to couchbase/cbft that referenced this issue Sep 21, 2016
Removing 'prod' from GOTAGS has the effect that the
blevesearch/segment library will be built with the non-switch-case
state machine generated code.  This should allow golang 1.7 to finish
compilation.

See also: golang/go#17127

Change-Id: I497794056e4b9f0c13d6c852c3901de582f13359
Reviewed-on: http://review.couchbase.org/67863
Reviewed-by: Hari Kodungallur <hari.kodungallur@couchbase.com>
Reviewed-by: Marty Schoch <marty.schoch@gmail.com>
Tested-by: Steve Yen <steve.yen@gmail.com>
ns-codereview pushed a commit to couchbase/cbft that referenced this issue Sep 28, 2016
Removing 'prod' from GOTAGS has the effect that the
blevesearch/segment library will be built with the non-switch-case
state machine generated code.  This should allow golang 1.7 to finish
compilation.

See also: golang/go#17127

Change-Id: I497794056e4b9f0c13d6c852c3901de582f13359
Reviewed-on: http://review.couchbase.org/67863
Reviewed-by: Hari Kodungallur <hari.kodungallur@couchbase.com>
Reviewed-by: Marty Schoch <marty.schoch@gmail.com>
Tested-by: Steve Yen <steve.yen@gmail.com>
(cherry picked from commit 9f2a7a4)
Reviewed-on: http://review.couchbase.org/68105
Reviewed-by: Steve Yen <steve.yen@gmail.com>
Tested-by: Hari Kodungallur <hari.kodungallur@couchbase.com>
@randall77
Copy link
Contributor

Probably not a dup of #16407 after all. Reopening.

@randall77 randall77 reopened this Oct 3, 2016
@randall77
Copy link
Contributor

After CL 30163 (new phi building algorithm), this example compiles for me in ~8 minutes. Most of the time (~7 min) is lowered CSE.

As an experiment, I changed CSE's cmpDepth from 4 to 1 and it compiled in under 1 minute.
@tzneal , was there a particular reason cmpDepth is 4? My uninformed opinion is that it seems high.

@tzneal
Copy link
Member

tzneal commented Oct 4, 2016

IIRC, it was a good value given some benchmarks I was using. So much has changed since then though, that it may not be a good choice anymore.

@gopherbot
Copy link

CL https://golang.org/cl/30257 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/30354 mentions this issue.

gopherbot pushed a commit that referenced this issue Oct 5, 2016
To refine a set of possibly equivalent values, the old CSE algorithm
picked one value, compared it against all the others, and made two sets
out of the results (the values that match the picked value and the
values that didn't).  Unfortunately, this leads to O(n^2) behavior. The
picked value ends up being equal to no other values, we make size 1 and
size n-1 sets, and then recurse on the size n-1 set.

Instead, sort the set by the equivalence classes of its arguments.  Then
we just look for spots in the sorted list where the equivalence classes
of the arguments change.  This lets us do a multi-way split for O(n lg
n) time.

This change makes cmpDepth unnecessary.

The refinement portion used to call the type comparator.  That is
unnecessary as the type was already part of the initial partition.

Lowers time of 16361 from 8 sec to 3 sec.
Lowers time of 15112 from 282 sec to 20 sec. That's kind of unfair, as
CL 30257 changed it from 21 sec to 282 sec. But that CL fixed other bad
compile times (issue #17127) by large factors, so net still a big win.

Fixes #15112
Fixes #16361

Change-Id: I351ce111bae446608968c6d48710eeb6a3d8e527
Reviewed-on: https://go-review.googlesource.com/30354
Reviewed-by: Todd Neal <todd@tneal.org>
@golang golang locked and limited conversation to collaborators Oct 5, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants