I'm completely new to DotMemory. The only memory profiler I've used in the past was Valgrind, so I'm probably overlooking something trivial.
I'm working on trying to find memory leaks in an application we're working on, using the following tutorial: https://www.jetbrains.com/help/dotmemory/How_to_Find_a_Memory_Leak.html
While analyzing the comparison of snapshots, the tutorial shows the following screenshot:
While, on my screen, there is no "Outgoing", "Key" or "Incoming" references tab at all:
Am I overlooking something, or is there a difference between versions? How do I get a list of references and retention paths?
Any help is welcome.
There are several objects of type "Settings_Part" in your snapshot, so you see an "Object set" view, which allows analyzing a set of objects. To see an "Object" view from the help article you need to scope to one object. To do this, use "Instances" view to see all objects instances in the set and choose one to analyze. Or if you not sure that all of these objects retained in the same way, you can use "Similar retention" view first to split these objects into clusters by different retention path, scope to one of them and then, use "Instances" view as described above.
Related
For context, using C# inside the Unity3D Editor.
I have more and more often started using enums to loosely couple things to settings.
For example i am setting up an item, and i want to give it a visual from a pool of defined visuals. That visual is basically a class that contains a sprite, a color, and a model attached to an integer unique ID. From this Unique ID, i generate an Enum. And it takes some effort to verify that the UniqueID is actually Unique, and catch some edge cases regarding that.
The benefit of doing the above, is that the enum is all that has to be stored on the item, to link it to the visual. At runtime there is a dictionary created to lookup the enum, and then request the stored visual to be loaded/used. This loosely couples the visuals to the item, so loading the item list does not automatically load all of the visual assets associated with the item. The last part is unity default behavior and is really annoying, and it really slows down the game and consumes a massive amount of RAM in this default behavior.
As a result we have a lot of those enums for various purposes and a lot of lookup stuff happening. And currently we are having no big problems with it.
However, the enums and the editing/generation of those enums is error prone in the sense that when values are removed, the items (and any other interested parties) are non the wiser, which then has to be either tested before build, or runs into a safety catch/error at runtime.
My question is. Is this a blatant abuse of Enums? And if so, what would be a better way of approaching this problem of loose coupling?
If it is not, what would be a better way to set up and manage these enums in a safe way? So alarm bells will go off if anything using the enum now has an invalid value, or the values meaning would change? Which i imagine is hardly possible, and requires code all over the place to "self check" on recompile?
Or does this just all boil down to team discipline to manage the values well, and know what the enums mean and represent? In which case, it would never be able to make this designer friendly unless i write a custom editor for each and every one of these.
Thanks for any insights you might be able to provide.
If I understand you correctly, you're trying to associate each item with one of multiple static visuals? If this is the case you can simply write each visual as a static readonly object inside the visuals class. In your "item" objects you can then make a field called e.g. "visual" and set this to reference the right visual.
I don't know what makes the visuals load, but if the constructor does, then I believe they will load when the visual class is first used at runtime.
I saw thisarticle in the link below and I wonder if you could help me with some questions I have
http://msdn.microsoft.com/en-us/library/ee330223(v=office.12).aspx
In our current project, which we didn’t not develop but we have to maintain, we are facing some issues, it looks like the first time the other firm developed the content types, they were done fine, using xml definitions, creating list templates and list instances was also done fine and in an organized way.
However at some point in time and after the content types and lists were already running on production, some changes had to be done (adding new fields to existing content types, changing translations of displayname or groupname, changing properties like required, showinnewform, showineditform, etc)
Across the internet I have found that many people have problems with unghosted content types, which means that the content type is detached from its XML definition, as far as I know this happens when somebody modified the child content type or list using the UI.
I am trying to collect a list of best practices for managing content types after they are deployed:
1.How to add a new field to an existing content type?
For this we have used UpgradeActions and AddFieldRef
2.How to remove an existing field from a content type?
For this, we haven’t needed it yet, but I have see that there also exist the RemoveFieldRef element which could be used inside UpgradeActions
3.How to reorder fields in a content type?
We do this by code in a custom upgrade action.
4.How to change a translation in an existing field?
We do this by code in a custom upgrade action.
5.How to change properties like ShowInDisplayForm, ShowInNewForm, Hidden, Required, etc.
We do this by code in a custom upgrade action.
I wonder if my list above specially points 3,4 and 5 can be called best practices, or if I am missing something or doing something wrong? Why? A few weeks ago we had a lot of problems, when doing changes via code and pushing down the changes was not working, the changes were not pushed(we were not seeing the changes in the lists). After reading for many hours, I saw that this might be possible due to that the list content type LINK is broken from its Parent content type definition.
I found that a way to restablish this link can be done using SQL but it’s not supported of course.
http://www.olavaukan.com/2010/10/content-types-can-be-unghosted-too/
http://soerennielsen.wordpress.com/2007/09/08/convert-%E2%80%9Dvirtual-content-types%E2%80%9D-to-physical/
Maybe somebody can guide me in the right direction?
Here's the story so far:
I'm doing a C# winforms application to facilitate specifying equipment for hire quotations.
In it, I have a List<T> of ~1500 stock items.
These items have a property called AutospecQty that has a get accessor that needs to execute some code that is specific to each item. This code will refer to various other items in the list.
So, for example, one item (let's call it Item0001) has this get accessor that may need to execute some code that may look something like this:
[some code to get the following items from the list here]
if(Item0002.Value + Item0003.Value > Item0004.Value)
{ return Item0002.Value }
else
{ return Item0004.Value }
Which is all well and good, but these bits of code are likely to change on a weekly basis, so I'm trying to avoid redeploying that often. Also, each item could (will) have wildly different code. Some will be querying the list, some will be doing some long-ass math functions, some will be simple addition as above...some will depend on variables not contained in the list.
What I'd like to do is to store the code for each item in a table in my database, then when the app starts just pull the relevant code out and bung it in a list, ready to be executed when the time comes.
Most of the examples I've seen on the internot regarding executing a string as code seem quite long-winded, convoluted, and/or not particularly novice-coder friendly (I'm a complete amateur), and don't seem to take into account being passed variables.
So the questions are:
Is there an easier/simpler way of achieving what I'm trying to do?
If 1=false (I'm guessing that's the case), is it worth the effort of all the potential problems of this approach, or would my time be better spent writing an automatic update feature into the application and just keeping it all inside the main app (so the user would just have to let the app update itself once a week)?
Another (probably bad) idea I had was shifting all the autospec code out to a separate DLL, and either just redeploying that when necessary, or is it even possible to reference a single DLL on a shared network drive?
I guess this is some pretty dangerous territory whichever way I go. Can someone tell me if I'm opening a can of worms best left well and truly shut?
Is there a better way of going about this whole thing? I have a habit of overcomplicating things that I'm trying to kick :P
Just as additional info, the autospec code will not be user-input. It'll be me updating it every week (no-one else has access to it), so hopefully that will mitigate some security concerns at least.
Apologies if I've explained this badly.
Thanks in advance
Some options to consider:
1) If you had a good continuous integration system with automatic build and deployment, would deploying every week be such an issue?
2) Have you considered MEF or similar which would allow you to substitute just a single DLL containing the new rules?
3) If the formula can be expressed simply (without needing to eval some code, e.g. A+B+C+D > E+F+G+H => J or K) you might be able to use reflection to gather the parameter values and then apply them.
4) You could use Expressions in .NET 4 and build an expression tree from the database and then evaluate it.
Looks like you may be well served by implementing the specification pattern.
As wikipedia describes it:
whereby business logic can be recombined by chaining the business logic together using boolean logic.
Have you considered something like MEF, then you could have lots of small dlls implementing various versions of your calculations and simply reference which one to load up from the database.
That is assuming you can wrap them all in a single (or small number of) interfaces.
I would attack this problem by creating a domain specific language which the program could interpret to execute the rules. Then put snippits of the DSL code in the database.
As you can see, I also like to overcomplicate things. :-) But it works as long as the long-term use is simplified.
You could have your program compile up your rules at runtime into a class that acts like a plugin using the CSharpCodeProvider.
See Compiling code during runtime for a sample of how to do this.
I was just curious if this is a good or bad practice or what the most preferred way of doing this is.
The practice I am referring to is that as I am a newb to WPF as I'm going along I have found it handy and useful to put strings, xdocuments, and domain objects into the Application.Resources in the app.xaml when their data is to be needed across the application, and for the simplicity of the static resource binding by x:key.
Good? Bad? Why? What should I do instead? Please no links to large MVVM tutorials and such, just looking for a concise answer regarding this specific practice, if MVVM has an answer for it I'm glad to hear what it is, I just don't want to read a 6 page tutorial or blog to find out..
I implement an application view model (AVM) object. Anything that needs to get exposed to the application views globally gets implemented as a property in the application view model so that I can get to it via binding. This makes for a nice consistent access method, gets me testability, implements property-change notification, gives me a place to put application-wide commands, all the stuff that you'd expect from using a view model.
The data context for every top-level window is set to the instance of the application view model. So I don't need to mess around with the resource dictionary or remember key values at all. That may sound a little weird at first - why would two windows use the same view model? - but if you want to put the same File/Exit command on every window that the application spawns, this actually makes logical sense. In such a case, the window's data context is set to the AVM, and then it contains a panel whose data context is set to a property on the AVM that's the actual context for that window. As long as you give your window element a name, binding to objects on the AVM is trivial - {Binding ElementName=TheWindow, Path=DataContext.TheProperty} - or you could expose the AVM as a property of the child view models.
The AVM pattern is subject to the same pitfalls as any one-object-to-rule-them pattern - e.g. creating a shambling beast with 200 unrelated properties. The solution's the same: aggregate those properties into service classes.
I generally don't put anything in the resource dictionary that doesn't get created in XAML. I can think of lots of valid exceptions to this general rule, but they haven't occurred in my programs yet.
Putting things in App.xaml could be a problem when:
You start branching your application into separate assemblies as the assemblies cannot 'see' app.xaml design-time - you can only find bugs run-time.
You have a magic string for pointing at your resource which is easy to misspell - or worse yet, duplicate by accident.
It is hard later to find the places any given resource is used and whether it can be safely changed ('What was it UpdateFrequency was for...')
You want it to be configurable - the AppSettings part of the app.config file is much better for these kinds of settings.
It's essentially the same problems as using global static variables for settings.
EDIT: Things, I prefer to have in App.Xaml is:
Global Styles and DataTemplates - in other words - things used for visual presentation that is there to override 'standard' settings - so usually they have no x:Key tag but rather a TargetType="{x:Type SomeType}"
Hope this helps!
This does make sense for ones shared across the application - "don't repeat yourself". I would also recommend having a project-specific resource that merges the application resources. The controls should reference that rather than the application resources.
This makes the controls in the project more self-contained.
I'd also recommend breaking resources into logical groups and merging them rather than having "one big bucket".
I am currently storing many different types of objects in the ASP.NET HttpRuntime.Cache and I was wondering if there is a way to figure out how big each object is?
Look at these questions:
Getting the size of a field in bytes with C#
Find out the size of a .net object
In particular, look for Jon Skeet's answer in those questions. They will tell you why the number won't be accurate.
As for getting an estimate, there is no way to do that unless there are certain criteria to be met for your object.
For instance, if you have many objects in the cache, sharing references to some common object instances, serializing out one of those objects in the cache will serialize out a copy of those common objects as well, inflating the results.
One thing you can do is serialize the object to a file on disk. That should give you an idea.
This cache manager from ASP Alliance might help as well