Is there a way to get the size of a file in .NET using a static method?

Question

I know the normal way of getting the size of a file would be to use a FileInfo instance:

using System.IO;
class SizeGetter
{
  public static long GetFileSize(string filename)
  {
    FileInfo fi = new FileInfo(filename);
    return fi.Length;
  }
}

Is there a way to do the same thing without having to create an instance of FileInfo, using a static method?

Maybe I'm trying to be overly stingy with creating a new instance every time I want a file size, but take for example trying to calculate the total size of a directory containing 5000+ files. As optimized as the GC may be, shouldn't there be a way to do this without having to tax it unnecessarily?

Contagion

Are you sure that this is bottleneck of your app? I guess not then why bother. – Gorlovka

@Gorlovka It isn't so much as it being a bottleneck as it being a question of efficient use of the language and the garbage collector. Such things are always worth questioning, especially if you are unfamiliar with the nuances of the GC. It would not be the first time I've been accused of over-optimizing, but I rather err on the side of being overly concerned about such things rather than not bothering. Besides, it doesn't take but a few minutes to ask a question. – Contagion

Answer 1

Don't worry about it. First, allocation in .NET is cheap. Second, that object will be in gen 0 so it should be collected without much overhead.

Leontineleontyne

I had figured that, but being an old C++ guy, some old habits about optimization/efficiency die hard. – Contagion

@Contagion I have a feeling that internal working of FileInfo adds much more overhead than allocation and GC of the object itself. Also there's a right thumb rule -- save your time first. If it's not a bottleneck, don't bother. Usually small optimizations don't worth money your employer paid you while you was busy optimizing (at least in eyes of an employer). So my advice: concider it a bad habit and don't bother. ;) – Leontineleontyne

Answer 2

Don't worry about it.

• I've found a blog post of someone who measured the overhead of object creation in .NET (C# Object Creation Time Trials), and, as it turns out, creating 10,000 objects took 0.03 seconds, i.e., 3 µs per object. The time required to read the file length from the file system will surely dominate those 3 microseconds significantly.

• A lot of static methods in the .NET framework internally create objects and call instance methods on them (you can verify this by looking at the reference source or by using some reflection tool). You assume that a static method is faster. Do not make such assumptions. If you have two ways to do the same thing, measure which one is faster.

Eccentric

+1 for the blog link; good read, and spot on since I'm a C++-to-C# convert :) It's still taking some getting used to where the GC is concerned, and if it truly is that efficient, than you're right, my concern is unwarranted. Thanks – Contagion

Allocation is very cheap, but cleaning up may not be. – Melisenda

Allocation in C# is so cheap it's practically free. Cleaning up is hugely expensive. Cleaning up one object allocation, is approximately equivalent to copying a reasonably sized struct 1000 times. Thus the measurement in the blog post is just irrelevant, as it's not measuring the true cost. – Tweeze

Answer 3

If you really, really need a static method, use the native GetFileSize or GetFileSizeEx API. But keep in mind this will require a handle to the file from the CreateFile API.

You can also view the source of the FileInfo class:

http://referencesource.microsoft.com/#mscorlib/system/io/fileinfo.cs#4ee673c1a4ecad41

Dustindustman