tags:

views:

1502

answers:

7

I've always admired the original uTorrent program. It looked great, was less than 64kb, was extremely fast and had all the features I needed. Unfortunately the program is closed source (and becoming more bloated by the day) so I come to Stackoverflow for inspiration.

What methods do you recommend in writing fast, memory efficient and elegant programs on Windows?

While C# (and the whole .NET concept) are cool ideas I am more interested in 'purist' answers and the challenge of writing efficient, fast software for the Windows platform, much like the original uTorrent client. I don't mind allocating my own memory, doing my own garbage collection and creating my own data structures.

Recommendations on books, articles, libraries, IDEs (even efficient ways of getting more caffeine into my system) welcome.

+12  A: 

The Windows Template Library is geared towards what you want to do. It's a light-weight, template-based C++ wrapper for the Win32 API. With it, you don't have to go through the pain of direct Win32 coding, but it doesn't add a lot of overhead like MFC.

Eric
+6  A: 

If you want to optimize for the smallest possible memory footprint and you don't mind jumping through a bunch of hoops that the .NET CLR was invented to take care of for you, then writing a direct Win32API app and hooking to GDI+ is the way to go. Petzold was the definitive reference.

Really, though, it's sort of a fool's errand, since the .NET runtime is going to be loaded into the OS's memory whether your app uses it or not, so you may as well link to it.

Crashworks
Methought the .NET framework is loaded into every process separately, in the same manner as any other collection of DLL's. Or has this been recently changed?
Pontus Gagge
@Pontus Gagge: Your understanding is incorrect. The whole idea of DLLs from back in the Windows 3.x days was to avoid loading the same code more than once into memory. Both Win16 and Win32 share DLL code among processes (though through different mechanisms). DLLs appear in each process address space through the magic of virtual memory, but there is really only one instance of the DLL code in memory.
Greg Hewgill
.NET still does incur a memory overhead due to automatic memory management. Also, why use GDI+ unless you want to draw something (slowly)?
Joey
I'm assuming he wants a UI, and GDI is the most compact way to do it that I know of.
Crashworks
@Greg: of course writeable static data is still copied per process. I don't know how much of that there is in CLR in general, but almost certainly less than the size of the code required to reproduce the bits of it you'd otherwise be using...
Steve Jessop
Since Windows DLLs can be relocated, I wonder how they can always be only one instance of them.
Bastien Léonard
They use relative addressing, a task made easier by the x86's hardware memory segment registers and clever MMU.
Crashworks
@Greg: OK as far as x86 instructions go (thanks for the heads up: I've never looked too closely at that, since DLL hell usually made it a terrible idea actually to share the same non-O/S DLL's among different applications!). However, I wonder what happens with IL instructions (which constitutes a fair portion of the FW), and JIT:ed code -- at least the latter I believe is compiled and stored separately per process.
Pontus Gagge
+4  A: 

General: For smaller executables, #define WIN32_LEAN_AND_MEAN and VC_EXTRALEAN (assuming VS). Don't compile with debug symbols (you probably knew this). Use fewer libraries, and be user to only link the parts of libraries you need (VC's linker is pretty good about this, but don't touch optlink if you can help it).

Strip the relocation headers : Go to http://www.paehl.de/cms/oldtools and search for "ReduceEXE" (direct download link: http://www.paehl.de/reduce.zip ).

Run an executable packer: http://upx.sourceforge.net/ ... It uses up more memory at runtime and starts a bit slower, but the file is MUCH smaller.

If you care about file size more than speed, VC has an option to "optimize for size", which turns off some things like loop unrolling and function inling.

If you want to go hardcore (and don't care about all the software engineering advantages), try using fewer classes, preferring POS types without virtual functions instead. Wikipedia suggests that 6-13% of a program's execution time is spent doing virtual calls. Further, the vtables themselves take up (a LITTLE) memory, and size_t worth of memory at the beginning of every class instance (that has a virtual function) is allocated for the vtable pointer. IOW, "pure C" can end up being slightly faster (though if you find yourself emulating classes with function pointers, go back to C++).

Robert Fraser
"Don't compile with debug symbols" - debug symbols are created in an external PDB file. There's absolutely not reason not to generate them even for release builds (see http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/06/19/do-pdb-files-affect-performance.aspx)"If you care about file size more than speed, VC has an option to 'optimize for size'" - this actually turns into a speed performance more often than not - smaller size makes for less cache misses and page faults.
On Freund
@On Freund -- Not necessarily -- He didn't specifically mention VC++. VC implements debug info as a PDB, however if you compile with, say DMC or MinGW GCC, debug infor is included in the object files.
Robert Fraser
+6  A: 

The Demo Scene is a group of people who spend their free time trying to make impressive and very small executables, which usually render something in 3d to music. Often the entire demo (code, music, 3d data) compiles into a single executable that is compressed to 64k or an impressively small size for the content.

You might draw some inspiration from the demos and learning about how they are made will inform your obsession to create small executables.

Often, the key is to leverage as many 3rd party DLLs as possible that are installed with windows. Also, low level, custom coding of everything else is required.

Tom Leys
+7  A: 

uTorrent is written in C++ and uses the old fashioned Win32 API. Google Chrome is also written this way, so why not download the source code and learn from their code?

StackedCrooked
yes i agree with you. try to learn Win32 API and then you can create small and fast application. in the past i was using Delphi, it could create small size application as well and pretty easy to learn (Pascal language)
nightingale2k1
A: 

Notepad++ is also a very fast, highly optimized and very useful os program that could spark your inspiration. It's philosophy is similar to that of uTorrent. It uses the good old Win32 api which should still be the fastest you can go on Windows.

If you want to go really artistic, the demo scene is the perfect place to go. Although their code is not always open.

AndreasT
Can't fully agree with "Notepad++ is very fast, highly optimized". Sometimes it's slow enough on big files. And last releases were some buggy. Another lite and fast editor is AkelPad - http://akelpad.sf.net/ (It's ~100k in packed exe and ~250K in packed plugins)
zxcat
+5  A: 

The old "LIBCTiny" trick still works. With modern VC++ releases, you might need to turn of a few features.

Another good trick to know is the lstr* collection of functions in Kernel32. That's already in memory, so those functions might be a leaner choice.

MSalters