?

Log in

No account? Create an account

Drizzle, boost::unordered_multimap++

« previous entry | next entry »
Jul. 27th, 2010 | 10:47 pm

=========================================================================================================
REGRESSION REPORT 
=========================================================================================================
MACHINE:  drizzle-build-n01.wc1.dfw1.stabletransit.com
RUN ID:   324
RUN DATE: 2010-07-27T21:48:07.932094
WORKLOAD: innodb_1000K_readonly
SERVER:   drizzled
VERSION:  lp:drizzle/staging
REVISION: 1669
COMMENT:  1669: Brian Aker 2010-07-27 This patch turns the table_cache into boost::unordered_multimap.
=========================================================================================================

TRENDING OVER LAST 5 runs 
Conc   TPS       % Diff from Avg Diff       Norm?          Min        Max        Avg        STD       
=========================================================================================================
16       1993.10          +1.19%      23.37   within norms    1905.44    2010.28    1969.73      26.56
32       2676.28          +1.75%      46.11  outside norms    2568.20    2685.05    2630.17      33.22
64       2622.82          -2.09%     -56.00  outside norms    2613.02    2737.89    2678.82      43.09
128      2621.23          -0.61%     -16.15   within norms    2609.74    2662.30    2637.38      16.41
256      2598.18          +5.50%     135.46  outside norms    2406.50    2599.34    2462.72      68.67
512      2343.83         +52.30%     804.91  outside norms    1318.38    2347.49    1538.92     402.80
1024     1722.08        +104.66%     880.65  outside norms     614.65    1725.52     841.43     440.35


Boost::unordered_multimap versus the hand crafted MySQL HASH?

Boost wins by a long shot. The above is from sysbench. We run it on each and every push that goes into the main tree looking for regression.

Every so often we get to see the opposite happen :)

Thanks to this patch, "Table" now joins the ranks of what we call a "trusted object". This means we can start safely assuming that the destructor on it is working (most of the MySQL codebase was crafted in such a way that you can only use a very limited subset of C++). In all of the new code in Drizzle we can easily make use of C++. There are still a few older bits where we cannot. Having "Table" now work means we can safely work in a number of new areas in the server. One of the biggest changes that will be coming soon is the removal of LOCK_open for a number of new cases.

Link | Leave a comment | Share

Comments {9}

Boost for the win!

from: anonymous
date: Jul. 28th, 2010 11:17 am (UTC)
Link

It would be nice to read more about your experiences when it comes to understanding performance issues with boost components.

I'd also like to read about any experiences you might have with the Boost::asio suite.

Reply | Thread

Brian "Krow" Aker

Re: Boost for the win!

from: krow
date: Jul. 28th, 2010 03:54 pm (UTC)
Link

We haven't made use of Boost::asio, so I don't have much to say about it.

Thus far, with the exception of the handling of bitmaps, both the STL and Boost outperform by either some small degree or some very large degree all of the original containers/etc that were in MySQL.

Reply | Parent | Thread

Dossy

(no subject)

from: dossy
date: Jul. 28th, 2010 12:53 pm (UTC)
Link

However, the poisoning of the MySQL codebase through Drizzle's C++ likely means that it's no longer safe to embed ala libmysql in other applications, which is sad.

Reply | Thread

Brian "Krow" Aker

(no subject)

from: krow
date: Jul. 28th, 2010 03:52 pm (UTC)
Link

You mean libmysqld?

We haven't ever focused on making Drizzle an embedded database, that was never the goal.

On the same note though, we almost never saw anyone use MySQL as an embedded database. SQLite rules that particular niche.

Reply | Parent | Thread

Dossy

(no subject)

from: dossy
date: Jul. 28th, 2010 04:00 pm (UTC)
Link

Understood, and you're right - it's probably not an area that MySQL can really compete in, anyway. Just sad when a door is slammed shut, like that.

Reply | Parent | Thread

(no subject)

from: jeffrey_mcmanus
date: Jul. 28th, 2010 04:25 pm (UTC)
Link

when jeebus shuts a door, zeus opens a window.

Reply | Parent | Thread

Brian "Krow" Aker

(no subject)

from: krow
date: Jul. 28th, 2010 10:15 pm (UTC)
Link

One door slams shut, and another one opens :)

Trying to be the "everything" is in large part what got us into trouble in the first place. Too much baggage, and way too many features which never were completed.

Reply | Parent | Thread

*slam*

from: jimw
date: Jul. 29th, 2010 01:27 am (UTC)
Link

if there was ever a door that deserved to be shut with extreme prejudice, it's libmysqld.

Reply | Parent | Thread

Dreamer of the Day

(no subject)

from: iamo
date: Jul. 29th, 2010 06:24 am (UTC)
Link

Er, wait. Why does this eliminate embedability exactly? If we're talking about an SQLite type API it's not like you can't expose opaque handles to C++ objects and provide an API to clean them up. It certainly wouldn't be the first implementation of such a thing.

It might kill the particular implementation that mysql has, I suppose, but I don't see why it would be unsafe.

Reply | Parent | Thread