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?

Solution 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.

Solution 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.

Solution 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

Comments

[Will]

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

[Dmitry]

@Will 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. ;)

[Will]

+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

[Peter Mortensen]

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

[Yair Halberstadt]

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.