Monthly Archives: July 2005

Curvy: Part 1

I’ve been wanting to learn COM lately, and not knowing where to start I began in some of the MFC books I have. Admittedly, MFC hides quite a bit of COM complexity, but I figured it would be a good place to get my feet wet without getting scared.

My first test program is called Curvy (Actually, Curvy2 since I restarted it with the doc/view architecture). It’s a curve drawing program. You can use the left mouse button to create points on a curve, the right mouse button closes the curve, and you can change the control points and move the curves.

The fun part was implementing copy & paste. It uses the OLE clipboard and puts both its native format and a bitmap on the clipboard.

The other fun part was implementing OLE Drag & Drop. This took me a few times to get quite right, but the results are spectacular. You can drag shapes within a window as well as to other windows. Holding down the ctrl key will copy the shape instead.

The project is in VS .Net 2005 format, but the code will compile under previous versions of VS.

Click here to download.

Next stop for this? Implement a full OLE server so other programs can host Curvy components inside them!


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

Mr. Hatch and the Internet

Phil Windley, commentator, author and IT industry expert (and also a former professor and supervisor of mine) has a wonderful little statement about Senator Hatch.

I try to avoid posting politics on this blog, but I have to mostly-agree with Dr. Windley. I’ve long been very wary of Senator Hatch’s dangerous and lopsided proposals. He seems very much ignorant of the technical aspects of these issues and I think that he, frankly, shouldn’t be allowed to touch anything having to with the Internet or computers.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

London

Leticia and I want to express our sorrow and empathy for the brave people of London. While used to terror attacks in the past, this was a particularly egregious act of barbarism. May the families of those who lost loved ones be comforted and may those responsible be brought to certain and swift justice.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

Checking if a Directory Exists

I recently had to write a utility that moved hundreds of thousands of files to a new location under a different directory organization. As part of it, I checked to see if the destination directory already existed and if not, created it. At one point I wondered if it would just be faster to try and create it, and if it fails, assume that it already exists (remember, I’m dealing with hundreds of thousands of files here–anything to speed it up is very welcome).

Determining if a directory exists isn’t entirely straightforward. If you use .Net, you can use Directory.Exists(), but that function must use the Win32 API at some point and there is no Win32 API that determines the existence of a directory, so what is it doing?

Ah, but there is an API to get the attributes of a given filename.

[code lang=”cpp”]
BOOL DirectoryExists(const char* dirName)
{
DWORD attribs = ::GetFileAttributesA(dirName);
if (attribs == INVALID_FILE_ATTRIBUTES) {
return false;
}
return (attribs & FILE_ATTRIBUTE_DIRECTORY);
}[/code]

Note that if the function call fails it doesn’t necessarily mean that the directory doesn’t exist–it could be that the device is inaccessible, you don’t have security permissions, or any number of other things. To know for sure what’s going on, you would need to call GetLastError().

So what if you’re creating directories? Why not try to create them no matter what? That’s fine, but is that faster than checking to see if it exists first? Let’s test it.

[code lang=”cpp”]
BOOL CreateDirectory(const char* dirName)
{
return ::CreateDirectoryA(dirName,NULL);
}

for (int i=0;i

CreateDirectory(dirName);

}
[/code]

Results (10,000,000 iterations):
265.227 second(s) total
2.65227e-005 second(s) average iteration

Now let’s try checking first:

[code lang=”cpp”]
for (int i=0;i BOOL bExists = DirectoryExists(dirName);
if (!bExists) {
CreateDirectory(dirName);
}
}
[/code]

Results (10 million iterations):
103.24 second(s) total
1.0324e-005 second(s) average iteration

Over 2 .5 times faster!

Now, my simple test is retrying a single folder over and over, and it never actually creates anything. In my case for the utility I mentioned above, I’m creating far fewer directories than the number of files I’m moving to them (though still in the thousands). In that case, it’s definitely worth my time to check to see if the folder exists before trying to create it.

To me, it appears that unless the number of folders you’re creating is of the same magnitude as the number of files, it definitely makes sense to check first.

This goes to show that you can’t believe anything related to performance until you measure it for your application.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order: