FAQ
Go run my project need 3s~ in my local computer, and need 7s~ in a one core
vps without pkg cache.

But go install only need 0.2s in my local computer with pkg cache.

It takes 1.071s to go run my project with pkg cache.
It takes 3.261s to go run my project without pkg cache.
It takes 0.148s to go install my project with pkg cache.
It takes 0.017s to run the compiled binary file.

If I use go run with pkg cache,some changes I just made is ignored.

I think there is a huge performance improvement in go run and go build
command.



--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Karaziox at Feb 13, 2015 at 8:05 pm
    Build and run don't do that by design. Run shouldn't modify anything in
    your workspace. Build should only produce the executable you asked for. If
    you want the benefits of go install, I'd say you should use go install. Are
    there any reasons why you aren't?
    On Friday, February 13, 2015 at 3:01:58 PM UTC-5, bronze man wrote:

    Go run my project need 3s~ in my local computer, and need 7s~ in a one
    core vps without pkg cache.

    But go install only need 0.2s in my local computer with pkg cache.

    It takes 1.071s to go run my project with pkg cache.
    It takes 3.261s to go run my project without pkg cache.
    It takes 0.148s to go install my project with pkg cache.
    It takes 0.017s to run the compiled binary file.

    If I use go run with pkg cache,some changes I just made is ignored.

    I think there is a huge performance improvement in go run and go build
    command.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bronze man at Feb 13, 2015 at 8:15 pm
    I got your point.
    The reason is that go install can not build a single golang file,and go
    install can not run the compiled files.

    So I can write my own version of go run to get better performance.
    I can put my single golang file in to a temporary package,and go install
    that package,and run the compiled files.
    On Saturday, February 14, 2015 at 4:05:45 AM UTC+8, kara...@gmail.com wrote:

    Build and run don't do that by design. Run shouldn't modify anything in
    your workspace. Build should only produce the executable you asked for. If
    you want the benefits of go install, I'd say you should use go install. Are
    there any reasons why you aren't?
    On Friday, February 13, 2015 at 3:01:58 PM UTC-5, bronze man wrote:

    Go run my project need 3s~ in my local computer, and need 7s~ in a one
    core vps without pkg cache.

    But go install only need 0.2s in my local computer with pkg cache.

    It takes 1.071s to go run my project with pkg cache.
    It takes 3.261s to go run my project without pkg cache.
    It takes 0.148s to go install my project with pkg cache.
    It takes 0.017s to run the compiled binary file.

    If I use go run with pkg cache,some changes I just made is ignored.

    I think there is a huge performance improvement in go run and go build
    command.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Karaziox at Feb 13, 2015 at 8:23 pm
    Of course, building a single file is what go run is good at. But usually
    thoses files are not the ones taking multiple seconds build times. If you
    have a project I assume you have split this project in multiples files,
    with packages and all. The fact that go install doesn't run the binary is a
    simple matter of "go install && $GOPATH/bin/mybinary" on Linux, "go install
    && %GOPATH/bin/mybin.exe" on Windows etc.

    As I understand, you are using the single file for testing a non main
    package? I would suggest the use of the test facilities of go so you get
    reuseable tests after that. That would remove the need for go run.
    See http://golang.org/doc/code.html#Testing
    and http://golang.org/pkg/testing/ for more details on that.
    On Friday, February 13, 2015 at 3:14:58 PM UTC-5, bronze man wrote:

    I got your point.
    The reason is that go install can not build a single golang file,and go
    install can not run the compiled files.

    So I can write my own version of go run to get better performance.
    I can put my single golang file in to a temporary package,and go install
    that package,and run the compiled files.

    On Saturday, February 14, 2015 at 4:05:45 AM UTC+8, kara...@gmail.com
    wrote:
    Build and run don't do that by design. Run shouldn't modify anything in
    your workspace. Build should only produce the executable you asked for. If
    you want the benefits of go install, I'd say you should use go install. Are
    there any reasons why you aren't?
    On Friday, February 13, 2015 at 3:01:58 PM UTC-5, bronze man wrote:

    Go run my project need 3s~ in my local computer, and need 7s~ in a one
    core vps without pkg cache.

    But go install only need 0.2s in my local computer with pkg cache.

    It takes 1.071s to go run my project with pkg cache.
    It takes 3.261s to go run my project without pkg cache.
    It takes 0.148s to go install my project with pkg cache.
    It takes 0.017s to run the compiled binary file.

    If I use go run with pkg cache,some changes I just made is ignored.

    I think there is a huge performance improvement in go run and go build
    command.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bronze man at Feb 13, 2015 at 8:37 pm
    Thanks for your reply.

    I have a enter point of my project which is a main file import 10+ packages
    with 20+ subcommand.The whole project should have 100+ packages which is in
    GOPATH.One package have 2MB ip location data in source file which need
    compile 1s~.

    When I edited something to print something to debug and restart my server ,
    it takes 7s~ to compile that enter point file on my one core vps, and that
    is my problem.

    I think a single enter point of the project simplify many things.

    On Saturday, February 14, 2015 at 4:23:00 AM UTC+8, kara...@gmail.com wrote:

    Of course, building a single file is what go run is good at. But usually
    thoses files are not the ones taking multiple seconds build times. If you
    have a project I assume you have split this project in multiples files,
    with packages and all. The fact that go install doesn't run the binary is a
    simple matter of "go install && $GOPATH/bin/mybinary" on Linux, "go install
    && %GOPATH/bin/mybin.exe" on Windows etc.

    As I understand, you are using the single file for testing a non main
    package? I would suggest the use of the test facilities of go so you get
    reuseable tests after that. That would remove the need for go run. See
    http://golang.org/doc/code.html#Testing and http://golang.org/pkg/testing/
    for more details on that.
    On Friday, February 13, 2015 at 3:14:58 PM UTC-5, bronze man wrote:

    I got your point.
    The reason is that go install can not build a single golang file,and go
    install can not run the compiled files.

    So I can write my own version of go run to get better performance.
    I can put my single golang file in to a temporary package,and go install
    that package,and run the compiled files.

    On Saturday, February 14, 2015 at 4:05:45 AM UTC+8, kara...@gmail.com
    wrote:
    Build and run don't do that by design. Run shouldn't modify anything in
    your workspace. Build should only produce the executable you asked for. If
    you want the benefits of go install, I'd say you should use go install. Are
    there any reasons why you aren't?
    On Friday, February 13, 2015 at 3:01:58 PM UTC-5, bronze man wrote:

    Go run my project need 3s~ in my local computer, and need 7s~ in a one
    core vps without pkg cache.

    But go install only need 0.2s in my local computer with pkg cache.

    It takes 1.071s to go run my project with pkg cache.
    It takes 3.261s to go run my project without pkg cache.
    It takes 0.148s to go install my project with pkg cache.
    It takes 0.017s to run the compiled binary file.

    If I use go run with pkg cache,some changes I just made is ignored.

    I think there is a huge performance improvement in go run and go build
    command.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Karaziox at Feb 13, 2015 at 8:43 pm
    I'm sorry, at that point I do not understand what prevents you from using
    go install? After your change you can simply do the "go install" and
    restart the process, which will now use the new binary. Only the changed
    code and the main package will be compiled. I'm having trouble seeing what
    go run is doing there that go install wouldn't?
    On Friday, February 13, 2015 at 3:37:50 PM UTC-5, bronze man wrote:

    Thanks for your reply.

    I have a enter point of my project which is a main file import 10+
    packages with 20+ subcommand.The whole project should have 100+ packages
    which is in GOPATH.One package have 2MB ip location data in source file
    which need compile 1s~.

    When I edited something to print something to debug and restart my server
    , it takes 7s~ to compile that enter point file on my one core vps, and
    that is my problem.

    I think a single enter point of the project simplify many things.


    On Saturday, February 14, 2015 at 4:23:00 AM UTC+8, kara...@gmail.com
    wrote:
    Of course, building a single file is what go run is good at. But usually
    thoses files are not the ones taking multiple seconds build times. If you
    have a project I assume you have split this project in multiples files,
    with packages and all. The fact that go install doesn't run the binary is a
    simple matter of "go install && $GOPATH/bin/mybinary" on Linux, "go install
    && %GOPATH/bin/mybin.exe" on Windows etc.

    As I understand, you are using the single file for testing a non main
    package? I would suggest the use of the test facilities of go so you get
    reuseable tests after that. That would remove the need for go run. See
    http://golang.org/doc/code.html#Testing and
    http://golang.org/pkg/testing/ for more details on that.
    On Friday, February 13, 2015 at 3:14:58 PM UTC-5, bronze man wrote:

    I got your point.
    The reason is that go install can not build a single golang file,and go
    install can not run the compiled files.

    So I can write my own version of go run to get better performance.
    I can put my single golang file in to a temporary package,and go install
    that package,and run the compiled files.

    On Saturday, February 14, 2015 at 4:05:45 AM UTC+8, kara...@gmail.com
    wrote:
    Build and run don't do that by design. Run shouldn't modify anything in
    your workspace. Build should only produce the executable you asked for. If
    you want the benefits of go install, I'd say you should use go install. Are
    there any reasons why you aren't?
    On Friday, February 13, 2015 at 3:01:58 PM UTC-5, bronze man wrote:

    Go run my project need 3s~ in my local computer, and need 7s~ in a one
    core vps without pkg cache.

    But go install only need 0.2s in my local computer with pkg cache.

    It takes 1.071s to go run my project with pkg cache.
    It takes 3.261s to go run my project without pkg cache.
    It takes 0.148s to go install my project with pkg cache.
    It takes 0.017s to run the compiled binary file.

    If I use go run with pkg cache,some changes I just made is ignored.

    I think there is a huge performance improvement in go run and go build
    command.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bronze man at Feb 13, 2015 at 8:50 pm
    Thanks for your advice.
    I will write a new command line tool that replace go run.

    On Saturday, February 14, 2015 at 4:43:32 AM UTC+8, José Mélançon wrote:

    I'm sorry, at that point I do not understand what prevents you from using
    go install? After your change you can simply do the "go install" and
    restart the process, which will now use the new binary. Only the changed
    code and the main package will be compiled. I'm having trouble seeing what
    go run is doing there that go install wouldn't?
    On Friday, February 13, 2015 at 3:37:50 PM UTC-5, bronze man wrote:

    Thanks for your reply.

    I have a enter point of my project which is a main file import 10+
    packages with 20+ subcommand.The whole project should have 100+ packages
    which is in GOPATH.One package have 2MB ip location data in source file
    which need compile 1s~.

    When I edited something to print something to debug and restart my server
    , it takes 7s~ to compile that enter point file on my one core vps, and
    that is my problem.

    I think a single enter point of the project simplify many things.


    On Saturday, February 14, 2015 at 4:23:00 AM UTC+8, kara...@gmail.com
    wrote:
    Of course, building a single file is what go run is good at. But usually
    thoses files are not the ones taking multiple seconds build times. If you
    have a project I assume you have split this project in multiples files,
    with packages and all. The fact that go install doesn't run the binary is a
    simple matter of "go install && $GOPATH/bin/mybinary" on Linux, "go install
    && %GOPATH/bin/mybin.exe" on Windows etc.

    As I understand, you are using the single file for testing a non main
    package? I would suggest the use of the test facilities of go so you get
    reuseable tests after that. That would remove the need for go run. See
    http://golang.org/doc/code.html#Testing and
    http://golang.org/pkg/testing/ for more details on that.
    On Friday, February 13, 2015 at 3:14:58 PM UTC-5, bronze man wrote:

    I got your point.
    The reason is that go install can not build a single golang file,and go
    install can not run the compiled files.

    So I can write my own version of go run to get better performance.
    I can put my single golang file in to a temporary package,and go
    install that package,and run the compiled files.

    On Saturday, February 14, 2015 at 4:05:45 AM UTC+8, kara...@gmail.com
    wrote:
    Build and run don't do that by design. Run shouldn't modify anything
    in your workspace. Build should only produce the executable you asked for.
    If you want the benefits of go install, I'd say you should use go install.
    Are there any reasons why you aren't?
    On Friday, February 13, 2015 at 3:01:58 PM UTC-5, bronze man wrote:

    Go run my project need 3s~ in my local computer, and need 7s~ in a
    one core vps without pkg cache.

    But go install only need 0.2s in my local computer with pkg cache.

    It takes 1.071s to go run my project with pkg cache.
    It takes 3.261s to go run my project without pkg cache.
    It takes 0.148s to go install my project with pkg cache.
    It takes 0.017s to run the compiled binary file.

    If I use go run with pkg cache,some changes I just made is ignored.

    I think there is a huge performance improvement in go run and go
    build command.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Harmen B at Feb 13, 2015 at 8:53 pm
    If you really want to keep using `go run`, for whatever reason, at least
    `go install` the libraries/packages. If you run `go run -v yourfile.go` it
    will show you which packages it compiled. Make sure you've `go install`-ed
    those.
    On Fri, Feb 13, 2015 at 9:50 PM, bronze man wrote:

    Thanks for your advice.
    I will write a new command line tool that replace go run.

    On Saturday, February 14, 2015 at 4:43:32 AM UTC+8, José Mélançon wrote:

    I'm sorry, at that point I do not understand what prevents you from using
    go install? After your change you can simply do the "go install" and
    restart the process, which will now use the new binary. Only the changed
    code and the main package will be compiled. I'm having trouble seeing what
    go run is doing there that go install wouldn't?
    On Friday, February 13, 2015 at 3:37:50 PM UTC-5, bronze man wrote:

    Thanks for your reply.

    I have a enter point of my project which is a main file import 10+
    packages with 20+ subcommand.The whole project should have 100+ packages
    which is in GOPATH.One package have 2MB ip location data in source file
    which need compile 1s~.

    When I edited something to print something to debug and restart my
    server , it takes 7s~ to compile that enter point file on my one core vps,
    and that is my problem.

    I think a single enter point of the project simplify many things.


    On Saturday, February 14, 2015 at 4:23:00 AM UTC+8, kara...@gmail.com
    wrote:
    Of course, building a single file is what go run is good at. But
    usually thoses files are not the ones taking multiple seconds build times.
    If you have a project I assume you have split this project in multiples
    files, with packages and all. The fact that go install doesn't run the
    binary is a simple matter of "go install && $GOPATH/bin/mybinary" on Linux,
    "go install && %GOPATH/bin/mybin.exe" on Windows etc.

    As I understand, you are using the single file for testing a non main
    package? I would suggest the use of the test facilities of go so you get
    reuseable tests after that. That would remove the need for go run. See
    http://golang.org/doc/code.html#Testing and http://golang.org/pkg/
    testing/ for more details on that.
    On Friday, February 13, 2015 at 3:14:58 PM UTC-5, bronze man wrote:

    I got your point.
    The reason is that go install can not build a single golang file,and
    go install can not run the compiled files.

    So I can write my own version of go run to get better performance.
    I can put my single golang file in to a temporary package,and go
    install that package,and run the compiled files.

    On Saturday, February 14, 2015 at 4:05:45 AM UTC+8, kara...@gmail.com
    wrote:
    Build and run don't do that by design. Run shouldn't modify anything
    in your workspace. Build should only produce the executable you asked for.
    If you want the benefits of go install, I'd say you should use go install.
    Are there any reasons why you aren't?
    On Friday, February 13, 2015 at 3:01:58 PM UTC-5, bronze man wrote:

    Go run my project need 3s~ in my local computer, and need 7s~ in a
    one core vps without pkg cache.

    But go install only need 0.2s in my local computer with pkg cache.

    It takes 1.071s to go run my project with pkg cache.
    It takes 3.261s to go run my project without pkg cache.
    It takes 0.148s to go install my project with pkg cache.
    It takes 0.017s to run the compiled binary file.

    If I use go run with pkg cache,some changes I just made is ignored.

    I think there is a huge performance improvement in go run and go
    build command.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bronze man at Feb 13, 2015 at 9:04 pm
    Thanks for your advices.
    I am using `kmg gorun` to work around setting GOPATH problem.
    I just need to add some code to kmg. It should be easy.
    On Saturday, February 14, 2015 at 4:53:55 AM UTC+8, Harmen B wrote:

    If you really want to keep using `go run`, for whatever reason, at least
    `go install` the libraries/packages. If you run `go run -v yourfile.go` it
    will show you which packages it compiled. Make sure you've `go install`-ed
    those.

    On Fri, Feb 13, 2015 at 9:50 PM, bronze man <bronz...@gmail.com
    <javascript:>> wrote:
    Thanks for your advice.
    I will write a new command line tool that replace go run.

    On Saturday, February 14, 2015 at 4:43:32 AM UTC+8, José Mélançon wrote:

    I'm sorry, at that point I do not understand what prevents you from
    using go install? After your change you can simply do the "go install" and
    restart the process, which will now use the new binary. Only the changed
    code and the main package will be compiled. I'm having trouble seeing what
    go run is doing there that go install wouldn't?
    On Friday, February 13, 2015 at 3:37:50 PM UTC-5, bronze man wrote:

    Thanks for your reply.

    I have a enter point of my project which is a main file import 10+
    packages with 20+ subcommand.The whole project should have 100+ packages
    which is in GOPATH.One package have 2MB ip location data in source file
    which need compile 1s~.

    When I edited something to print something to debug and restart my
    server , it takes 7s~ to compile that enter point file on my one core vps,
    and that is my problem.

    I think a single enter point of the project simplify many things.


    On Saturday, February 14, 2015 at 4:23:00 AM UTC+8, kara...@gmail.com
    wrote:
    Of course, building a single file is what go run is good at. But
    usually thoses files are not the ones taking multiple seconds build times.
    If you have a project I assume you have split this project in multiples
    files, with packages and all. The fact that go install doesn't run the
    binary is a simple matter of "go install && $GOPATH/bin/mybinary" on Linux,
    "go install && %GOPATH/bin/mybin.exe" on Windows etc.

    As I understand, you are using the single file for testing a non main
    package? I would suggest the use of the test facilities of go so you get
    reuseable tests after that. That would remove the need for go run. See
    http://golang.org/doc/code.html#Testing and http://golang.org/pkg/
    testing/ for more details on that.
    On Friday, February 13, 2015 at 3:14:58 PM UTC-5, bronze man wrote:

    I got your point.
    The reason is that go install can not build a single golang file,and
    go install can not run the compiled files.

    So I can write my own version of go run to get better performance.
    I can put my single golang file in to a temporary package,and go
    install that package,and run the compiled files.

    On Saturday, February 14, 2015 at 4:05:45 AM UTC+8, kara...@gmail.com
    wrote:
    Build and run don't do that by design. Run shouldn't modify anything
    in your workspace. Build should only produce the executable you asked for.
    If you want the benefits of go install, I'd say you should use go install.
    Are there any reasons why you aren't?
    On Friday, February 13, 2015 at 3:01:58 PM UTC-5, bronze man wrote:

    Go run my project need 3s~ in my local computer, and need 7s~ in a
    one core vps without pkg cache.

    But go install only need 0.2s in my local computer with pkg cache.

    It takes 1.071s to go run my project with pkg cache.
    It takes 3.261s to go run my project without pkg cache.
    It takes 0.148s to go install my project with pkg cache.
    It takes 0.017s to run the compiled binary file.

    If I use go run with pkg cache,some changes I just made is ignored.

    I think there is a huge performance improvement in go run and go
    build command.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kevin Malachowski at Feb 15, 2015 at 6:16 pm
    Try adding the -x flag when you run go run/build/install to see commands are being run.

    At least on my machine, the first time I run 'go install -x .' it shows all the libraries that are not fresh being recompiled and cached in the $GOPATH/pkg directory. Later when changing just the main func and re-running with 'go run -x main.go' (or build) only the main package is recompiled, all other libraries have their cached version used. If you change a library you import go build/run will always recompile it but not cache it. As others have said, use go install to get the caching functionality.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 13, '15 at 8:02p
activeFeb 15, '15 at 6:16p
posts10
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase