Are there any restrictions by number of dependencyobjectsp/dependencyproperties per project?
edited: or per process/domain? I'm interesting in any kind of limits.
+1
A:
There is probably a very, very high limit on the number of dependency values that you can have in any process (and this number is probably less that the maximum number of normal property values that you can have floating around), but it wouldn't be per project...
Rob Fonseca-Ensor
2010-03-03 13:44:44
+4
A:
Number of DependencyProperties defined
An AppDomain cannot have more than 65535 different DependencyProperties defined, though each property defined can be applied to many DependencyObjects.
A Process can have multiple AppDomains so it can have a number of DependencyProperties limited only by RAM. Since a DependencyProperty definition (not usage!) takes around 150 bytes, a 32 bit process is limited to about 20 million DependencyProperties defined.
Number of DependencyObjects created
A Process or AppDomain can have a number of DependencyObjects limited only by RAM. A minimal DependencyObject requires 64 bytes, so a 32 bit Process or AppDomain can have about 46 million DependencyObjects created.
Number of DependencyProperties applied to DependencyObjects
A Process or AppDomain can have a number of DependencyProperties applied to DependencyObjects limited only by RAM. It requires 8 bytes to store a DependencyProperty on a DependencyObject, so a 32 bit Process or AppDomain can have up to about 375 million DependencyProperty settings on its DependencyObjects, depending on other RAM usage.
64 bit WPF
Similar calculations for 64 bit WPF would suggest the following limits, though I have not verified them:
- 65535 DependencyProperty definitions per AppDomain
- 120 quadrillion DependencyProperty definitions per Process
- 280 quadrillion DependencyObjects per Process or AppDomain
- 2.3 quintillion DependencyProperties actually set on DependencyObjects per Process or AppDomain
Maximum numbers of DependencyProperties and DependencyObjects per project
The number of DependencyProperties or DependencyObjects that can be created by a given project depends primarily on the length of time you can get someone to run your program, since a project can go on creating AppDomains full of DependencyProperties and DependencyObjects and destroying them repeatedly for as long as it runs.
If the universe exists another trillion years and you can get someone to run your project that long on hardware that is at least as fast as that we are using today, I would estimate that you could create roughly 1 decillion DependencyProperties or DependencyObjects in that trillion years, all using a single VS.NET project.
If instead we are talking about the number of DependencyProperties that can be added to the code, a VS.NET project with custom build steps can theoretically include any number of input files and build any number of output files. These files can be on the internet, so the limit is not the amount of space to store the input and output, nor is it the compile time: It is the number of developers it requires to write all that code. If you had a million developers working on your single project for a trillion years and each developer could add one DependencyProperty to the project every 3 seconds, you would end up with about 1 septillion DependencyProperties defined at the end of the trillion years.
Of course all of this is rather silly... The only practical constraint is the limit of 65535 DependencyProperty definitions per AppDomain.
Update
Truth be told, even 65535 DependencyProperties per AppDomain is insanely huge. Each DP corresponds to a conceptually separate application feature. The whole of WPF, Blend and VS.NET 2010 put together contain fewer than 1000 DPs.
An application that used all 65535 available DPs would be several hundred million lines of code and would not fit in a 32 bit address space or be developable by anyone but billion dollar company.
Thus the danger of running out of DependencyProperties in any application produced in the next ten years is pretty much nonexistent. The exception would be if a developer misused DependencyProperties by creating them on the fly in their code.
Ray Burns
2010-03-03 15:17:33
Thanx:) That's really full answer))
Zim
2010-03-03 16:50:42
+1. One decillion, eh? Just started a test process now. I'll get back to you with the results...
Kent Boogaart
2010-03-03 18:49:59
Great! Let me know when you pass 999 nonillion, will you? ;)
Ray Burns
2010-03-03 19:32:11
Hmm. So one could, conceivably, programmatically generate types using Reflection, and then programmatically generate dependency properties from their properties. I wonder if there's a reason anyone would do that other than wanting to see if they could make the DP system break. I speak as someone who had to build a workaround into a WinForms app to keep it from running out of window handles.
Robert Rossney
2010-03-03 20:41:35
It's easy to **artificially** exceed the 65535 limit: `for(int i=0; true; i++) DependencyProperty.Register(i.ToString(), typeof(string), typeof(Window));` On the other hand, all of WPF has only about 500 Distinct properties and adding VS.NET 2010 and Blend put together doesn't take it over 1000, so it would be a fantastically complex application that would actually use thousands of different DPs
Ray Burns
2010-03-03 21:25:15
This is very different from a WinForms app where you use a handle for every control you create: A DependencyProperty is a programmer-defined concept, so you only get one per new feature of your application, if that (AddOwner on an existing property does not count against this limit). This is why even truly enormous applications will rarely have as many as 1000 DependencyProperties.
Ray Burns
2010-03-03 21:27:53