[
https://issues.apache.org/jira/browse/CASSANDRA-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181691#comment-13181691
]
Eric Evans commented on CASSANDRA-3634:
---------------------------------------
bq. for throughput, BB is consistently about 10% faster on inserts, and about
equal on reads, across all row types
Since there isn't anything here wildly inconsistent with my results, I'd
summarize it as ~10% faster on inserts, and about equal on reads, counter
increments, and index inserts.
bq. BB has substantially lower latency for large values on reads
I don't see how this test can be correct since the cost of parsing the query is
identical no matter how wide the rows are, or how large the values.
bq. something is fishy w/ BB stdev that might be worth investigating
(generating extra garbage somehow)?
This was consistent with what I saw as well, though for the life of me I can't
imagine what's causing it.
bq. 10% faster writes is a big enough deal that I'm in favor of committing the
BB version for 1.1.
It's not nearly so compelling to me. 10% is definitely on the high side of
making me stand up and take notice, but it's not enormous.
It's also limited to inserts, and requires that you completely saturate the
processors to make it evident at all, which is not a typical workload. That
doesn't make it irrelevant, just more relevant to those conducting benchmarks
than to real users.
On the other side, what's at stake is increased complexity for an arbitrary
number of clients, and a proven vector for bugs. And, to make this class of
bug even more interesting, it has the potential to make otherwise identical
queries return different results depending on whether they use the prepared
statement API, or the conventional one.
THAT BEING SAID: I've heard from enough people that were following the results
as they came in to know that most people (engineers?) have a hard time looking
past a simple faster/slower distinction, (even when the difference in question
was _much_ less than 10%). If others feel the same, that we should give up
this abstraction for 10% faster standard writes, then I won't belabor the point
further.
> compare string vs. binary prepared statement parameters
> -------------------------------------------------------
>
> Key: CASSANDRA-3634
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3634
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
> Reporter: Eric Evans
> Assignee: Eric Evans
> Priority: Minor
> Labels: cql
> Fix For: 1.1
>
>
> Perform benchmarks to compare the performance of string and pre-serialized
> binary parameters to prepared statements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
