I spent a good part of yesterday writing up a little bit of a "memory object cache" (whatever ;-), that preallocates objects, as to avoid insessant calls to malloc() for objects of the same size.

This is useful for example in a hash table, or linked list implementation, you usually have "buckets," elements that act as container for every element in the structure. By preallocacting these buckets you can gain a nice performance increase (on my little hash implementation, i gained an average of 25% improvement). Its also useful when implementing scripting languages (VHLL's, which is why I wrote it), when your language has a base type (for example in PHP, its a "zval"), that is really created and destroyed quite often, avoiding malloc'ing and free'ing a few thousand times is quite nice.

Anyhow, the code is quite small, and available at:

http://www.bumblebury.com/csexp101.tgz

the relevant files are

memobj/memobj.[ch]

and you can see the difference by::

time ./test.memobj
time ./test.normal

To implement it, I used a two dimensional array, that way you avoid fragmentation, and still have reasonable performance. I'll write up something a little more formal later..

It truly amazes me sometimes how today's programmers are turning out. I'm one of the PHP developers, and as such, I get to see alot of new people starting to program.

Everyone starts somewhere....

But what constantly shocks me is the hubris of these new programmers. People who have just started using PHP, maybe have written a small intranet, maybe a website, who knows maybe a website that gets 100,000 hits a day (hardly anything these days), and they come to the php development list and start lecturing PHP developers on how the "enterprise" looks at php and how we should change PHP's development.

We then tell them, for example, thank you very much but we will not make parse errors something that can be "catchable" by the user. Why, because:

1) Its not how languages should work, a basic check of your code (you know, running it _before_ you deploy it) will reveal such parse errors.

2) Technically, a parse error leaves the engine in an unstable state, meaning its simply not possible.

Of course, these "enterprise" programmers, know better. They try and explain that handling of parse errors is needed to give PHP enterprise acceptance.

Please.

Now the fact that they continually argue is annoying, its like a little fly, that no matter how much you want to, you can't swat it, "that's bad for the community." Still, that's not the part that shocks me - personally, I think I'm right, even when I argue with people that have more experience than me. We all have to learn. What is unbearable about these people is the way in which they argue.

"PHP needs this for enterprise acceptance" "This is an error in your way of thinking" "You're not in touch with what real users want" etc.

If you're new, or just a plain bad programmer, that's fine, everyone should have a voice, everyone should have the opportunity to learn, in fact its what keeps a community vibrant: new developers come in, they may not have the most skills in the world, but they learn and then eventually become productive members of the community.

What is infinitely irritating is when a new or inexperienced developer comes, and lectures us on his "one true vision," and refuses to learn from people who *do* in fact know a bit more then him. He can't let an issue lie, he has to argue every single comment made by every single developer in attempt to prove to us that he knows more and is correct. "Hey let's all of PHP's error messages be stored in XML format!" In place of intelligent thought, let me use a buzzword!

I've always wanted to experiment with writing an Advogato diary but never really had the time -- besides, who is interested in my boring drivel... Still, I figure if I constantly write in this thing, perhaps some of you folks will look at the projects I'm working on -- so, if you haven't already go, go, look!

Lately I've been working on two projects, phpaga and mod_haydn. But this entry is really about the problems related to phpaga.

phpaga was written with the MySQL data container. MySQL is an excellent system when you need to insert data quickly and retrieve data quickly, but when it comes to the needs normally associated with a database, it is woefully incompetent.

For example views, read only containers, which provide a "view" of data across multiple tables in one psuedo-table don't exist, sure, I could wait till MySQL 5.0 for SQL '88 compliance, but why should I? The problem doesn't start there - you want Foreign keys, Triggers, Stored Procedures, Blobs (no, not TEXT field aliases)? Good luck! MySQL doesn't even support Sequences (no, Auto Increment is not a sequence.)

Why am I whining like a troll? Two reasons:

1) We can't drop MySQL support for a real database, so many people these days seem to have only MySQL installed, so alienating them by dropping MySQL support is shooting yourself in the foot - akin to writing GUI applications without support for 16 bit OS' like Win32.

Our current solution for handling views is simply to use temporary tables (only when MySQL is used). For sequences we have to create index tables, incremented along with the insertions (this is PEAR DB's solution to the problem).

This is ugly and its a pain in the ass to maintain. Ohh well, at least MySQL is free software, that makes me feel so much better.

2) The folks at MySQL AB would have you believe that MySQL is a real database. Calling MySQL a RDBM is like calling Oracle a flat file: its true on one-level, false on every-other level.

If I wasn't dependent on it, I might actually find it humorous - "MySQL has row level locking!", "MySQL has transactions!" - so what? - there is no database worth mentioning that doesn't have these features.

This isn't to say that MySQL isn't a great tool, its wonderful for specialized/small tasks, its also a very easy entry point for users who don't know about databases or SQL. But when it comes to being "Enterprise Ready" or "Industrial Strength," please, be reasonable, Microsoft Access is more "Enterprise Ready" (it does support FOREIGN KEY constraints.)

MySQL is fine when you don't need a database and don't want a text file.