These two side-by-side screen captures are from CrystalDiskMark measuring the performance of my brand new Samsung 850 PRO 256GB Solid State Drive (C:) versus the performance of my old Seagate Barracuda 1TB 7200 RPM 32MB Cache Hard Disk Drive (D:). Higher numbers are better.

Both devices are capable of SATA III, but my machine only has SATA II. Under SATA III, I would expect the HDD to perform somewhat faster, but the SSD to perform a lot faster. I will update this post when I upgrade to SATA III.

As a developer, I have configured MySQL to launch automatically at startup, because I will probably be using it, if this is a workday, and if my computer is starting up during work hours, and if my work these days involves databases. That’s a lot of ifs. Quite often, I launch it but do not use it, so, it would be nice if it is as unobtrusive as possible. Unfortunately, it is obtrusive in at least one way: it occupies a large amount of memory, which is unreasonably large for a piece of software that is just sitting there doing nothing.

In this post I show how to configure it to occupy as little memory as possible.

The following image shows the mind-boggling amount of memory occupied by MySQL 5.6 server on Windows 7 64-bit.

(This is despite the fact that during installation I explicitly specified that this MySQL server is going to be used for development, not for production.)

A quick search on the web shows that this preposterous amount of memory can be reduced to something less preposterous by editing my.ini (usually found in some place like ProgramData\MySQL\MySQL Server 5.6) and replacing the following line:

table_definition_cache=1400

with this line:

table_definition_cache=400

Unfortunately, even though the savings are huge, the memory footprint of mysql is still nothing short of gargantuan:

Old comments

• Nat 2015-02-16 14:12:53 UTC

  Hey Michael, do you have a contact email? I’d like to run a few things by you but I can’t seem to find any contact details.

  • michael.gr 2015-02-16 14:39:37 UTC

    Okay, I guess I need to fix that. I suppose I should post a picture containing my email address on the blog. In the mean time, you can contact me by sending an email to any address at this domain.

    Read more »

This post does not contain any spoilers, unless you would consider as a spoiler my opinion on how the quality if the movie varies as the movie progresses. (Or the image below.)

Picture source: cgmeetup.com

So, I watched The Dawn of the Planet of the Apes yesterday, and what can I say, wow, it blew my mind. I started watching it having very low expectations, and I was very pleasantly surprised for about one hour and fifty minutes of its total two hour and ten minute duration, which includes the end titles. Then, starting with the “I am saving the human race” incident, it transformed into the crap that I had expected from the beginning, perhaps even worse, but that does not annul the fact that the first one hour and fifty minutes were one of the most pleasant movie watching experiences I have had in quite some time.

Exceptions are the best thing since sliced bread. If you use them properly, you can write code of much higher quality than without them. I think of the old days before exceptions, and I wonder how we managed to get anything done back then. There is, however, one little very important thing missing from implementations of exceptions in all languages that I know of, and it has to do with transactions.

At a high level, exception handling looks structurally similar to transactional processing. In both cases we have a block of guarded code, during the execution of which we acknowledge the possibility that things may go wrong, in which case we are given the opportunity to leave things exactly as we found them. So, given this similarity, it is no wonder that one can nicely facilitate the other, as this sample code shows:

Here is a check list for creating useful bug reports:

1. Before reporting, make sure that you are using the latest version of the software.

2. Before reporting something as a bug, make sure it is in fact a bug.

3. Before reporting, play around with the bug to identify it with at least a bit of accuracy.

4. Report through the proper channel, usually an issue tracking system.

5. Make sure that the bug has not already been reported.

6. Invest some time to find a proper title for the bug.

7. State the name of the product in which you found the bug.

8. State the version of the product in which you found the bug.

9. Describe your environment (Operating System name and version, etc)

10. List the steps to reproduce the problem.

11. State the “observed result” of following the steps.

12. State the “expected result” of following the steps.

13. State the reproducibility of the bug. (Or your best estimate of it.)

14. Stick to the facts.

15. Address only one bug per bug report.

16. Include any useful attachments.

Here is a slightly more detailed discussion of each one of the above items: