Like a midget at a urinal, I would have to be on my toes

[Alimonster]

Interesting! Looks like there are certain conditions that cause bloat with strings.

I declared a string globally (var x: string. This increased the file size from 8K to 8.5K. However, if I initialised it at the same time (var x: string = 'blah') then the filesize jumped to 13.5K! Hmm! The same test with an integer didn't increase the filesize - nor did PChars or ShortStrings.

Another tidbit: declaring the strings as vars inside a procedure didn't increase the file size at all.

I still want to get rid of that bloody RTL though. Some day...

[TheLion]

Could those problems with Strings be caused by the effect that Delphi doesn't treat Strings like Strings (Char[255]) anymore, but sees them as an AnsiString (16 bytes) now?

[Alimonster]

Yes and no, I think. They're not shortstrings any more, but rather pointers. They use a copy-on-write dealie with reference counting. This means that for each string, you get a pointer to the data, a reference count and a length (this is hidden from you). This means that you get memory allocation when using them (sometimes).

The problem would seem to be that it uses some memory allocation behind the scenes - maybe. I seem to recall reading that this is the case, and that it introduces a little overhead (maybe in Ray Lischner's Delphi in a Nutshell book?). Something's fishy there, anyway. It's quite interesting that assigning it a value in the global area gives a massive increase in the exe size! I'd imagine that dynamic arrays would also cause bloat. I'll check now...

YEP! Declaring a dynamic array (var x: array of integer) increases the size up to 8.5K (half a K). If I then use SetLength, the size jumps up to 16K! It looks like the memory management is playing silly buggers. If I use a pointer to integer + getmem then there **was the same size increase as with strings** to 13.5K.

I tried declaring a pointer to an integer and using LocalAlloc instead (a win32 function). Guess what? No size increase - 8K still . I'm not sure what alloc function is best (apparently LocalAlloc and GlobalAlloc are the same, and HeapAlloc seems slightly more involved, in that you have to create it first(?)).

Another interesting result! I've found that declaring a global var as a string array, like this...

[pascal]var x: array[0..0] of string = ('blah');[/pascal]

...increased the size to 14K (that's one K more than a normal string, even though it amounts to the same thing). Hmm! (Again, an array of 1 integer, initialised, didn't increase the exe size).

It looks like you should watch out for strings, since they're dynamically managed behind the scenes! The same goes for GetMem or New and dynamic arrays.

It's probably an idea to wrap up memory allocation around the Win32 API calls, then.

Anyone else tried stuff like this? What interesting results are still to come...

[Michalson]

Well Alimonster asked me to reply to this, I guess because I coded a 999 byte graphical demo just after 4E3 (Link). This is going to disappoint you guys but it wasn't coded in Delphi (it isn't even a Windows executable) and to be blunt, despite the fact that I love Delphi (except for tiny demos and web stuff I do all my personal programs in it), it just isn't that good for making small executables, nor was it intended to be. If you want to code small stuff you're going to want to use a tight C compiler or do it in pure assembler. Of course if all you want to do is entry a 64K competion (64K is a lot, especially now that you don't have to write your own 3D engine and can just use OpenGL/DirectX) then Delphi isn't too much of a disadvantage. Once you get over the minimum size the code you add (assuming you don't add libraries) is not going to make a large impact on the size of the exe (again, so long as the code doesn't require any large libraries).

...I'll try making a "small" Delphi app tonight. If I get something smaller than what has already been described I'll post it and explain the methods.[/url]

[Alimonster]

Actually, I knew that thing was done in asm and that's one of the reasons I asked you to post here . It seems to me that you'd know more about the internal structure of the PE format, since you've got down to the nitty gritty. I'm hoping that you can bring some of that knowledge to bear - such as nice things to include for {$SetPEFlags} and {$SetPEOptFlags} (Delphi 6+) that could have a bearing on some of the things that the compiler doesn't have options for (unfortunately).

Also, I seem to recall from a gamedev thread that you have access to the code for the RTL (i.e., a better Delphi than Personal Edition), though I could be wrong there. (The thread where somebody asked for the source to System.pas, I think, is the one from which I got that impression.) I only have the Delphi 5 version, which is no use for D6 (I simply couldn't get the damned thing to accept the new .dcu, no matter how many brick walls I hit my head against).

I'm under no illusions that it wouldn't be better to use C++ (w/ Rasmus' 1.5K OpenGL init code at Flipcode) or asm (for obvious reasons). However, that's a moot point to me. I'm wondering how small can Delphi go since it will make my life easier. Also, I'm trying to see if I can match the 4K bump mapping in Turbo Pascal just for personal kicks (there's an article about this in one of the Hugis, IIRC). Of course, I'm not there yet... I may experiment with the Free Pascal Compiler later on, depending on how this goes.

[Xorcist]

I've tried modifying the compiled .dcu units without luck - if I had the VCL source for D6 then I'd be all set, dammit. Oh well - 5.5K is good enough for now.

Would it be illegal for me to give you the VCL source? Cause I have the Professional Edition, and wouldn't mind wrapping up the whole VCL source directoy and sending it over to you to better the cause. Let me know.

P.S. I have both Delphi 5.0 and 6.0 Professional Editions.

[TheLion]

About those increased size when strings are being used:

Today I was browsing through my compiler settings and found an option called HUGE STRINGS, now I don't have a lot of experience with compiler setting/directives, but did you have this turned on or off during testing

[Alimonster]

*Slaps forehead*

That could make a difference there, of course! ShortStrings don't require memory allocation in the same way as big 'uns (AnsiStrings). I'd imagine that would make a difference. Well spotted! ShortStrings are simply 256-char long strings with the size stored in array position [0] of the string (which you can't directly access).

I'll try that later on today!

[Mrwb]

Hey, stumbled accross this thread earlier today, and thought i'd have a go in size optimizing. I took the code from example 2.1a at sulaco, stripped it, (got rid of "useless" stuff like error messaging ) stripped it some more, and then stripped it even more. The exe was still to big. When packed with upx, it was 13-15kb or something. Then, I downloaded a modified system.pas file, and voilA , the exe was down to 12kb unpacked. After lots and lots of "optimizing", I managed to get the code down to 9kb unpacked (9 216bytes to be excact, with three rotating cubes, two wireframed and one solid).
After deleting the RCData package info and overwriting the resource dvclal with an empty file using ResourceHacker, the file lost a couple of bytes. I then downloaded a program called Realign which realigns Windows EXE files and deletes the DOS stub, making the file more compression friendly. I also used FakeCom.com which is an a small program, "which extracts data contained at the end of file and runs it". If you upx' the file after these operations, it will compress the whole file. (otherwise it won't tuch the exe headers)

The result: a 3 609 byte Delphi OpenGL program which displays three rotating cubes; two wireframed and one solid.

Im sure it can be optimized even further.

BTW: I also made a version with a simple noise texture generator (from the thread at the OpenGL forums), which resulted in an 4 462 byte app.

Inspiration gathered from http://scene.migeel.sk/intro4k.html

[WILL]

Oooww... very cool.