Mason Wheeler's thoughts on Delphi programming in general, and particularly on the technical aspects of developing the TURBU engine and editor.
Posts tagged ‘Delphi’
About a year and a half ago, I reported on how slow the original implementation of TValue in Delphi 2010 was, touching off a storm of comments and various other blog posts as other Delphi community members conducted similar experiments. One thing that came out of it was a suggestion by Robert Love on how to improve performance by adding code to optimize for the most common cases. Continue reading ‘XE2: TValue is much faster now’ »
Since D2009 at least, I’ve never managed to get a new Delphi release to install correctly on the first try. Each time, it’s been the same basic problem. Each time, I’ve contacted Embarcadero about it and asked them to fix it. Unfortunately, they still haven’t. Continue reading ‘XE2: New Delphi, same old broken installer’ »
One of the biggest challenges in working on the TURBU engine has been minimizing load times. Some large projects have a whole lot of data to work with, which could take the better part of a minute to load if I tried to load it all up front. No one wants to sit and wait for that, so I’ve pared down the loading so that only the stuff that’s needed right away gets loaded from the project database right at startup.
And yet, on one of my larger test projects, that wasn’t enough. One of the things that has to be loaded upfront was map tile data, so that the maps can draw. Unfortunately, this project has over 200 different tilesets, and it was taking quite a while to load that much data. I’ve got a RTTI-based deserializer that can turn dataset records into objects, but it was taking a completely unreasonable 3.3 seconds to read the tile data.
Continue reading ‘How default settings can slow down FastMM’ »
Last year when I was at Delphi Live, the event was a bit smaller than it had been the year before. Less attendees, less sessions, not as nice of a venue, etc. Kind of to be expected, with the economy in the toilet and all, but still it was sorta sad. I heard a few people mention that the way things had gone, they doubted there would be another one this year.
Just yesterday I was thinking back on that, and I figured it was probably right, or we would have heard an announcement about it by now. And that kinda sucked. I’d really enjoyed going there the last two years. Well, I’m glad to be able to say I was wrong about that.
I wrote my last post about enabling booleans in Firebird after several hours of poking around in database code trying to get my query to execute without errors. Once it worked, everything seemed great. But I missed an important step: I hadn’t tried to write anything back to the database yet.
Firebird is a great database, but it’s got one really irritating drawback: no native support for the boolean type. The standard solution to this issue is to create a BOOLEAN domain as a special restricted version of a smallint, and then make your database driver output the correct type.
The first part is easy. The second, not so much, if you want to use DBExpress. This really should be handled internally as a special case inside the DBX driver. Unfortunately neither Embarcadero nor Chau Chee Yang, maker of the alternative dbExpress Firebird driver, has released the source to their drivers, neither driver handles the BOOLEAN domain, and neither driver has any sort of callback/event handler that you can set up to intercept and modify the schema of a query result. But I’m not gonna let a little thing like that stop me! Continue reading ‘Adding boolean support to Firebird+DBX’ »
One annoying thing I’ve noticed in building my script compiler is the way the use of generic collections tends to bloat up the size of your EXE. I use generics for a lot of things; a compiler uses lists, stacks and lookup tables (dictionaries) all over the place. When I was building it with DeHL, the compiler plus a very simple test frontend compiled into a 36 MB behemoth of a binary, and a quick look at the mapfile shows that the vast majority of that was DeHL collections. Now that I’ve switched to the more simplified Collections library, it “only” takes 23 MB, a savings of about 33%. But that’s still huge. There has to be a better way.
Over the past couple weeks, I’ve been working on refining and testing my RTTI generation and the scripting system I’ve been building on top of it, which I’ve decided to call RTTI Script. I think I’m finally starting to get something ready for public consumption. I set up a Google Code repository this morning for RTTI Script, but so far all it contains is the RTTI generation code. The actual compiler and script executor still need some work. Continue reading ‘RTTI Generation code now available’ »
A few years back, I ran across this post by Hallvard Vassbotn. (It’s a shame he stopped blogging, because he always had some very interesting stuff about the technical details of how stuff in Delphi works.) At the bottom was a paragraph that really fascinated me:
On a more technical level it suffices to say that they use custom and extremely compact and fast data structures, tricks and hacks to be able to represent millions and millions of objects within the constraints of a 32-bit Windows system. Throw in the use of Physical Address Extensions, storing per-class information in “virtual” class vars to reduce object instance size, creation of classes and their VMTs dynamically at runtime (!!), pointer packing, multithreading, the list just goes on and on.
Continue reading ‘Dynamic class creation: moving beyond the theoretical’ »
One of the biggest complaints about the extended RTTI introduced in Delphi 2010 is the way it adds so much to the size of your EXE. Well, in a recent StackOverflow answer, Barry Kelly hinted that the format of the basic RTTI structures in TypInfo.pas are “more likely to change from version to version now that it has a much higher level abstraction in the Rtti unit.” Continue reading ‘Smaller, cleaner RTTI coming?’ »