Small Footprint: Reducing Bloat with Modular DLLs and Control Sets

You'll see throughout our site that we say our controls have a "small footprint." We've constructed our controls to reduce bloat at every turn, guaranteeing that you won't bog down your app. As you know, when you add a control to your application, you're adding the dll (dynamic link library)—a small program that will run whenever your user decides to interact with the FlexGrid. If your third-party references are all contained in a single executable, even though you only need to use that one small program, you're still running a bunch of other small programs at the same time. Here's a look at the assembly size for FlexGrid for WPF, one of our most popular controls:

Control Class

Size

C1.WPF.C1FlexGrid
(base class)

289KB

C1.WPF.FlexGrid.GroupPanel.4
(allows grouping)

94KB

C1.WPF.FlexGridFilter.4.dll
(allows filtering)

125KB

Total Package

508KB

You're probably starting to get the picture here.

Why get a U-Haul when you only need a wagon?

You're already building an application—possibly a single large executable, maybe something with small dlls—so needing another large executable from a third-party control set just bloats your application needlessly. It's like asking for a wagon and getting a U-Haul. Our modular references have been designed to ensure that you get maximum power, with minimum overhead. For instance, in WinForms, we provide separate DLLs for every control. Some bigger controls are even broken up into smaller, "auxiliary" assemblies. For instance, DataGrid for WPF has auxiliary assemblies for Excel export, advanced filtering and grouping capabilities. So if you don’t need Excel export, then you don’t bloat your app with the unnecessary code that could even lead to unwanted bugs. We have little overhead, and a light page state.

That's the definition of a small footprint.