FAQ
http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/


Any thoughts on that? Why is the Go alternative slower? Maybe Apache Maven
has some optimzations to make it faster than Go http?

--

Search Discussions

  • Raph at Sep 18, 2012 at 3:09 pm
    This surely depends on the implementation of both the Java and the Go
    services.
    In cases where the communication overhead is bigger than the actual work,
    latency will increase with concurrency (not only in Go, but in general).
    Can you provide the source code?
    On Tuesday, September 18, 2012 3:46:35 PM UTC+1, Anssi Porttikivi wrote:


    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/


    Any thoughts on that? Why is the Go alternative slower? Maybe Apache Maven
    has some optimzations to make it faster than Go http?
    --
  • Chris Hines at Sep 18, 2012 at 4:12 pm
    According to the first part of the blog the code is here:
    https://github.com/collinvandyck/go-and-java
    On Tuesday, September 18, 2012 11:03:46 AM UTC-4, Raph wrote:

    This surely depends on the implementation of both the Java and the Go
    services.
    In cases where the communication overhead is bigger than the actual work,
    latency will increase with concurrency (not only in Go, but in general).
    Can you provide the source code?
    On Tuesday, September 18, 2012 3:46:35 PM UTC+1, Anssi Porttikivi wrote:


    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/


    Any thoughts on that? Why is the Go alternative slower? Maybe Apache
    Maven has some optimzations to make it faster than Go http?
    --
  • Raph at Sep 18, 2012 at 3:26 pm
    It doesn't look like there's any explicit synchronization happening - can I
    assume that the concurrency is being managed by the http.Handle call? I'm
    not familiar with the net/http API.
    Did you ever profile this code to see where the latency is coming from?
    On Tuesday, September 18, 2012 4:10:12 PM UTC+1, Chris Hines wrote:

    According to the first part of the blog the code is here:
    https://github.com/collinvandyck/go-and-java
    On Tuesday, September 18, 2012 11:03:46 AM UTC-4, Raph wrote:

    This surely depends on the implementation of both the Java and the Go
    services.
    In cases where the communication overhead is bigger than the actual work,
    latency will increase with concurrency (not only in Go, but in general).
    Can you provide the source code?
    On Tuesday, September 18, 2012 3:46:35 PM UTC+1, Anssi Porttikivi wrote:


    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/


    Any thoughts on that? Why is the Go alternative slower? Maybe Apache
    Maven has some optimzations to make it faster than Go http?
    --
  • Rob Pike at Sep 18, 2012 at 4:18 pm
    I don't know if it will help his particular case but there has been
    significant performance work, and much still to come, that has a
    dramatic effect on the performance of some benchmarks like this. Even
    what's at tip now is much faster than go1.0.2 because of changes to
    the compiler and run-time.

    Leaving aside the general unreliability of benchmarks.

    -rob

    --
  • Bryanturley at Sep 18, 2012 at 9:14 pm

    On Tuesday, September 18, 2012 9:46:35 AM UTC-5, Anssi Porttikivi wrote:

    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/


    Any thoughts on that? Why is the Go alternative slower? Maybe Apache Maven
    has some optimzations to make it faster than Go http?

    Your post says "as a web server", but you are also making calls to an sql
    server.
    If you wanted to measure web serving you should take out all the sql calls
    and serve up static files.

    --
  • Patrick Higgins at Sep 18, 2012 at 11:23 pm

    On Tuesday, September 18, 2012 12:20:53 PM UTC-6, bryanturley wrote:

    On Tuesday, September 18, 2012 9:46:35 AM UTC-5, Anssi Porttikivi wrote:


    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/


    Any thoughts on that? Why is the Go alternative slower? Maybe Apache
    Maven has some optimzations to make it faster than Go http?

    Your post says "as a web server", but you are also making calls to an sql
    server.
    If you wanted to measure web serving you should take out all the sql calls
    and serve up static files.
    I think the test author is not a part of this thread. I forked the code at
    https://github.com/patrick-higgins/go-and-java and have confirmed that DB
    access is not the same between the two implementations. Using prepared
    statements in Go doubled throughput in my very simple testing.

    --
  • Brad Rydzewski at Sep 19, 2012 at 1:39 am
    hmm, that's interesting ... because the author uses db.Query(), which uses
    db.Prepare() under the covers ...

    374 func (db *DB) Query(query string, args ...interface{}) (*Rows, error) { 375 stmt, err := db.Prepare(query)

    On Tuesday, September 18, 2012 4:23:22 PM UTC-7, Patrick Higgins wrote:
    On Tuesday, September 18, 2012 12:20:53 PM UTC-6, bryanturley wrote:


    On Tuesday, September 18, 2012 9:46:35 AM UTC-5, Anssi Porttikivi wrote:


    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/


    Any thoughts on that? Why is the Go alternative slower? Maybe Apache
    Maven has some optimzations to make it faster than Go http?

    Your post says "as a web server", but you are also making calls to an sql
    server.
    If you wanted to measure web serving you should take out all the sql
    calls and serve up static files.
    I think the test author is not a part of this thread. I forked the code at
    https://github.com/patrick-higgins/go-and-java and have confirmed that DB
    access is not the same between the two implementations. Using prepared
    statements in Go doubled throughput in my very simple testing.
    --
  • Jesse McNelis at Sep 19, 2012 at 1:52 am

    On Wed, Sep 19, 2012 at 11:39 AM, wrote:
    hmm, that's interesting ... because the author uses db.Query(), which uses
    db.Prepare() under the covers ...

    func (db *DB) Query(query string, args ...interface{}) (*Rows, error)
    {
    stmt, err := db.Prepare(query)
    Yep, and that means it has to do a db.Prepare() for every query which
    requires an additional round trip to the database.
    The database driver could cache this itself, but it doesn't.
    --
    =====================
    http://jessta.id.au

    --
  • Kevin Gillette at Sep 19, 2012 at 3:41 am
    I'm glad it doesn't cache, since caching increases complexity and adds more
    processing time and memory usage in the best case (when caching isn't
    needed). Since Go encourages a "culture of competence" much more so than,
    say, Java, we enjoy lower overhead (semantic overhead, at the very least),
    we don't mollycoddle those who don't understand what they're doing at the
    expense of those who do.

    To be honest, almost all of the benchmarks (especially in blogs) that I've
    seen concerning Go are from those who are just first trying out the
    language, and are not in a position to do it any kind of justice. The
    stress on benchmarks, for me, is a sign that they may have gotten so far as
    to learn the syntax, but not the _language_, and so they don't yet know
    what Go really has to offer. Those who have well integrated into the Go
    mindset often do not to care either way: they know the performance is
    competitive and they know how to make reasonable effort-to-efficiency
    tradeoffs, and even if it was not nearly as efficient, they may still have
    reservations "going back" to their previous language, since performance is
    hardly our only feature.
    On Tuesday, September 18, 2012 7:52:11 PM UTC-6, Jesse McNelis wrote:

    On Wed, Sep 19, 2012 at 11:39 AM, <brad.ry...@gmail.com <javascript:>>
    wrote:
    hmm, that's interesting ... because the author uses db.Query(), which uses
    db.Prepare() under the covers ...

    func (db *DB) Query(query string, args ...interface{}) (*Rows, error)
    {
    stmt, err := db.Prepare(query)
    Yep, and that means it has to do a db.Prepare() for every query which
    requires an additional round trip to the database.
    The database driver could cache this itself, but it doesn't.
    --
    =====================
    http://jessta.id.au
    --
  • Raggi at Sep 19, 2012 at 4:45 am

    On Tuesday, September 18, 2012 7:46:35 AM UTC-7, Anssi Porttikivi wrote:

    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/


    Any thoughts on that? Why is the Go alternative slower? Maybe Apache Maven
    has some optimzations to make it faster than Go http?
    Without even optimizing anything, I highlighted a few issues and different
    results here:

    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/#comment-655206246

    I may continue a little more after dinner... maybe.

    --
  • Sam Freiberg at Sep 19, 2012 at 4:02 pm
    Are there any plans to make the database connection pool size configurable?
    On Sep 18, 2012, at 8:58 PM, raggi@google.com wrote:



    On Tuesday, September 18, 2012 7:46:35 AM UTC-7, Anssi Porttikivi wrote:
    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/

    Any thoughts on that? Why is the Go alternative slower? Maybe Apache Maven has some optimzations to make it faster than Go http?

    Without even optimizing anything, I highlighted a few issues and different results here:

    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/#comment-655206246

    I may continue a little more after dinner... maybe.

    --
    --
  • Chandru at Sep 20, 2012 at 6:06 am
    Why is it that in raggi's test, Go lit up only 2 cores while Java used all
    8? Was GOMAXPROCS not set to a large enough value?

    --
    Chandra Sekar.S

    On Wed, Sep 19, 2012 at 9:00 PM, Sam Freiberg wrote:

    Are there any plans to make the database connection pool size configurable?

    On Sep 18, 2012, at 8:58 PM, raggi@google.com wrote:


    On Tuesday, September 18, 2012 7:46:35 AM UTC-7, Anssi Porttikivi wrote:

    http://boundary.com/blog/2012/**09/17/comparing-go-and-java-**
    part-2-performance/<http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/>


    Any thoughts on that? Why is the Go alternative slower? Maybe Apache
    Maven has some optimzations to make it faster than Go http?
    Without even optimizing anything, I highlighted a few issues and different
    results here:


    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/#comment-655206246


    I may continue a little more after dinner... maybe.

    --




    --

    --
  • Henrik Johansson at Sep 20, 2012 at 8:08 am
    On my system Go beats Java with all the tools except ab. I have always
    suspected ab but can't really say why...

    Everything run locally.

    Java 1.7 (latest from Oracle and after warmup)
    Request rate: 4360.1 req/s (0.2 ms/req)

    Go go1.0.2
    Request rate: 7044.9 req/s (0.1 ms/req)

    Tip (version devel):
    Request rate: 8424.2 req/s (0.1 ms/req)

    This was taken from httperf output and may or may not be relevant but
    saying that Java "wins" is clearly not the whole truth at least
    The results from ab is different and Java heads it and for siege it is a tie.

    The observation that the Go program don't saturate the cores is true
    here at least. No matter the GOMAXPROCS setting it is fairly low on
    CPU. The Java version does not do much better but clearly more cpu is
    used even when the result is worse.

    These little benchmarks are a fun distraction but I agree with the
    general consensus that real metrics are really hard to produce and
    even harder to trust.

    / Henrik

    On Thu, Sep 20, 2012 at 8:00 AM, Chandru wrote:
    Why is it that in raggi's test, Go lit up only 2 cores while Java used all
    8? Was GOMAXPROCS not set to a large enough value?

    --
    Chandra Sekar.S

    On Wed, Sep 19, 2012 at 9:00 PM, Sam Freiberg wrote:

    Are there any plans to make the database connection pool size
    configurable?

    On Sep 18, 2012, at 8:58 PM, raggi@google.com wrote:


    On Tuesday, September 18, 2012 7:46:35 AM UTC-7, Anssi Porttikivi wrote:


    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/

    Any thoughts on that? Why is the Go alternative slower? Maybe Apache
    Maven has some optimzations to make it faster than Go http?

    Without even optimizing anything, I highlighted a few issues and different
    results here:


    http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/#comment-655206246

    I may continue a little more after dinner... maybe.

    --




    --

    --
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 18, '12 at 3:09p
activeSep 20, '12 at 8:08a
posts14
users13
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase