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:
|C1.WPF.C1FlexGrid (base class)||289KB|
|C1.WPF.FlexGrid.GroupPanel.4 (allows grouping)||94KB|
|C1.WPF.FlexGridFilter.4.dll (allows filtering)||125KB|
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.