In our upcoming MariaDB 5.3 release Monty optimized the internal string append code for performance. I tested his patch with a plain MariaDB 5.2 vs. a patched MariaDB 5.2 with sql-bench, which showed an overall performance gain around 3%.

The details of the patch Monty describes like this

Patch to optimize string append:

While examining a trace output from a mysql-test-run case, I noticed a
lot of reallocation calls.  This was strange as MariaDB/MySQL was
designed to do so few malloc/realloc as possible.  The system uses was
to first calculate how big buffer you would need and then allocate a
buffer big enough for most usage. Then there was some safety calls to
extend the buffer if needed.

What had happened in the MySQL code over time was that new coders was
using a buffer that was not preallocated and it was filled with a lot
of append calls(), each which caused a new realloc().

I fixed a couple of the worst cases to prealloc the buffer properly,
and for the other cases I made a general fix by making the
reallocation addaptive:

The essence was to replace the realloc() call with the following function:

In MySQL 5.3, this gave a speedup for some test cases (in debug mode)
with 25 %.  For an optimized version of MySQL we got a general
performance boost of 3 %.  The difference comes from the fact that
we do a lot of extra checks for the malloc() call in a debug build and
fewer malloc() calls gives a notable speed improvement.

The full patch can be seen by doing this in the MariaDB 5.3 tree:
bzr log  -p -r monty@askmonty.org-20101108114354-jl61qx8e36gvbzm7

Here are the detailed results of the sql-bench runs. I ran sql-bench with MariaDB 5.2.2 with default settings and used MyISAM as storage engine.

Column 1 is in seconds. All other columns are presented relative
to this. 1.00 is the same, bigger numbers indicates slower.

1) MariaDB 5.2.2.
2) MariaDB 5.2.2 patched with Monty’s string append optimization.
3) MariaDB 5.2.2 patched with Monty’s string append optimization.
4) MariaDB 5.2.2 patched with Monty’s string append optimization.

The number in () after each tests shows how many SQL commands the particular
test did.  As one test may have many different parameters this gives only
a rough picture of what was done.

I ran the test on a quite fast machine and therefore you can ignore the results with run times around 0 – 3 seconds. I am adjusting the tests to run at least for 5 seconds to have more reliable results.

As machine I used our new benchmark system “pitbull”, which I also used for benchmarking the MyISAM segmented key cache performance.

I’d like to wish Henrik Ingo well now that he has publicly announced his resignation from Monty Program. Henrik, I especially wish you all the best with the new member of your family.

I know you put a lot of effort into your presentation to the Monty Program board regarding transfer of trademark ownership, and you know (and I do not mind saying externally) that I supported transfer to a non-profit designed for such purposes. Our informal, non-inclusive vote in Istanbul aside, I think the company as a whole should put a lot of thought into such matters. I would always hope the board would do the same.

And it is my understanding that this is what is happening. Not that the board made a final decision to maintain trademark ownership, but that they decided more research and discussion are needed. And despite my knee-jerk reaction to go the Debian trademark route, I came to Monty Program from Canonical. Wiser legal and business minds have decided to retain the Ubuntu trademark for Canonical. Just as Red Hat has retained the Fedora trademark. So despite my inclinations I have to ask why others have chosen differently.

Trademark has value, and not just to investors. Spoofy domains exist for a reason. And I have to admit to trusting Canonical and Red Hat to protect their marks better than, again, Debian (SPI owns but does not manage).

This leads to two questions. First, who actually manages trademark issues? If organizations own but do not manage, in practicality if Monty Program transferred ownership of the MariaDB trademark, Monty Program would still be in the position of managing it. I have doubts about community-only enforcement of trademark issues (Debian people, you there?). So either way, people have to have faith in Monty Program handling their trademark management sanely. It’s not about ownership, it’s about management. Which leads to question two.

What is sane trademark management? Trusting a company to protect a mark is useless if you don’t trust the company. How far is too far, and who do you trust? Canonical and Red Hat both have clearly stated guidelines vis-a-vis use of their respective marks. Monty Program does not. So regardless of who actually owns the MariaDB trademark, MariaDB needs a trademark policy so that those who wish to use the trademark understand how the mark is managed.

Personally I think Canonical and Red Hat enforce their trademarks sanely. There does not seem to be much objection to the Ubuntu and Fedora trademark guidelines from the community at large. If MySQL made mistakes with regard to their trademark policy and management of it, I don’t think it’s fair to assume that Monty Program will necessarily repeat those same mistakes.

Of course, everyone has a different definition of “sane.” Monty Program employees, the company board, and the community have to decide what is sane for themselves. So I find myself in agreement with the board. We probably need more time to actually draft a trademark policy, and to discuss the real benefits and possible issues of any potential transfer. I’m beginning to think “the other guy does it,” or (“didn’t do it”) isn’t enough.

Fortunately, the need for a trademark policy has been known for some time. We are looking at various other projects’ policies, and will probably borrow liberally from our Free/open source peers. It is my hope that a draft trademark policy will be made available for community comment early in 2011, after employees have a chance to help create that initial draft. Colin and I have been driving most of this, and unless I have misunderstood some of the salient points, we have been told to create a draft that assures:

1). The MariaDB (and other Monty Program managed marks) always entertain fair use gracefully.

2). The MariaDB trademark is made available to users, hackers, companies and products as long as the usage doesn’t conflict with other usage, and the trademark licensor keeps a level of quality and follows well established open source conduct.

3). The marks will always be available, via a “public promise” approach to ownership transfer (should ownership not have been transferred from Monty Program previously). Failure of the company, or failure of the company to deliver, ends exclusive mark ownership.

4). Everyone understands what “fair use,” “made available,” “beneficial ways,” and “public promise” mean above, and to where mark ownership will revert. We have yet to really define what will trigger the switch. That will be presented in draft form, also, I am sure.

MariaDB will only survive if people hack it and use it, and are able to say they hack it and use it. We want this. Our trademark policy will reflect it, and assure that Monty Program can’t run off with the mark, or let it wither and die. But training, professional certifications, hardware certifications? These require trademark management. It’s probably a primary factor in the lack of official Debian certs. And no offense meant to you Debian, trademark management isn’t something I want to do, either. Good management starts with a sane policy. And we will have a policy soon.

I don’t think MariaDB and/or Monty Program are that far off-course. And I’m too involved in making MariaDB succeed to quit now.

There has been a lot happening in the MariaDB community recently, and there has been growth. Here are some of the highlights. Thank you to all our current contributors, and to others that want to contribute, shoot community[at]askmonty[dot]org an e-mail.

MariaDB 5.2.3 binaries for Solaris and Debian Sparc

Our Sparc community contributor, Mark, has continued to make popular binaries for Solaris 10 and Debian Sparc. He’s kept up to speed with MariaDB 5.2.3, so please visit him and download the binaries.

MariaDB 5.2.3 on the openSUSE Build Service

Community contributor Michal Hrušecký has packaged MariaDB for openSUSE and its available via the openSUSE build service. It is ready up to version 5.2.3, and is still in the unstable repository (it will progress further based on more testing). A benefit of the openSUSE build service is that it also churns out RPMs for CentOS, Fedora, Mandriva, Red Hat Enterprise Linux, openSUSE and SUSE Linux Enterprise.

MariaDB Virtual Machines

Again from Mark, he’s been working on creating virtual machines for people to test MariaDB with. He’s looking for feedback on which virtualization platform people are looking for VMs for. Currently there is a VM for CentOS 5.5 and Ubuntu 10.04 LTS. These are all 64-bit virtual machines. You can make use of them using VirtualBox.

Mirrors

Looking back at the releases page, we have made eleven 5.1 releases and four 5.2 releases. When we made our first 5.1 release we had one mirror (this was in April 2009). When we made our first 5.2 release, we had four mirrors (this was in April 2010). Today we are up to seven mirrors, and from recent requests I expect this to grow. If you want to mirror MariaDB, check out the Mirroring MariaDB guide on the AskMonty Knowledgebase.