Font being immutable distresses both the programmer and the GC, because you need to create a new instance every time.
Why is Font an immutable reference type then?
It simplifies the usage from the render system.
If the framework were to allow Font to be mutable, it would need to detect changes, and rework how it's rendering happens on a regular basis. Since Font creates a native resource, keeping this immutable prevents the system from worrying about having to recreate handles internally on a repeated basis.
Also, I disagree in terms of "Distress to the programmer". By making Font immutable, it makes it more obvious what is happening when the user creates a Font object. If you want a new Font, you need to create a new Font object, which in turn creates new native font resources. Making Font immutable makes it more clear what is happening - you're less likely to create a performance problem accidentally.
Were Font mutable, it would be less obvious that you were creating handles repeatedly as you changed your Font properties.
Well, ask yourself some questions.
First, is a font logically a mutable thing, like a grocery list, or an immutable thing, like a number? If you are modelling a grocery list in a program, it makes sense to make it mutable because you typically think of having one grocery list the contents of which change as you run out of or purchase particular items. But numbers you typically model as being immutable -- the number 12 is the number 12, now and forever.
I think of "Helvetica 12 point bold" as being a fixed, immutable thing, like a number, not something I can change.
Second, is a font logically more like a value that you can make copies of, or is it more like a single thing that you can refer to? I don't think of having "two copies" of Helvetica; I think of referring to Helvetica. Whereas numbers I think of as having different copies of for different purposes -- when I have 12 items on my grocery list and 12 keys on my keyring, I don't think of both of those things as "referring to 12".
Since I think of fonts as being immutable and referred to, rather than as mutable and copied by value, I personally would model fonts as immutable reference types. Perhaps your intuitions about fonts are different than mine.
They aren't structures because they need to have finalizers to wrap the underlying objects and provide a sensible IDisposable implementation. What happens if you Dispose() your own copy of a struct? Do you clone the handle each time?
It isn't really much stress on the GC...
It also allows the Font to be re-used safely without worry about it changing half way through an operation ;-p
I disagree this distresses the programmer. There are plenty of immutable types in the BCL which are used on a daily basis by programmers and don't cause any issues. System.String for example.
One of the benefits of being immutable is that you don't have to create a new instance every time. You can re-use the same Font type as often as you like because it's not going to change. On the other hand, if it were mutable, you would need to make a copy every time to help guarantee that no one else changed it out from under you.
Lastly, Font is not actually an immutable class in the strictest sense of the word. It implements IDisposable and in the Dispose method tears down the underlying native object.
You could argue that it distresses the developer. But you could also make the same argument in the opposite case.
For example:
// Let me just set the button to the same font as the textbox...
button.Font = textBox.Font;
// ...except that I want the button's font to be bold.
button.Font.Bold = true;
The above code would set a button and a textbox's font to bold at the same time if Font were mutable, contrary to the developer's expectations.
Font is a poorly designed object, which violates the Single Responsibility Principle, and the difficulties you cite stem from this. The problem with Font is that it encompasses two things: (1) a description of how a font should be drawn, and (2) a GDI font object for a font with those properties. The former type could be mutable without consequence, while making the latter type mutable would pose all sorts of problems.
Among other things, consider the question of how one should track the ownership of a typical control (e.g Button) Font property? If one will sometimes change the fonts associated with controls, should one create a separate Font object for each control, and Dispose of it when changing a control's font to something else, or should one keep a list of all the different fonts one is using so as to avoid creating an excessive number of identical Font objects, or what?
If there existed a FontDescription struct (which was mutable, and not IDisposable) and things like Control.Font were of type FontDescription (or better yet, Control exposed a SetFont method with parameter of type FontDescription), the above question could be answered pretty simply. As it is, the most efficient approach for setting the Font of a control is to create a new font object (if one doesn't already have a suitable one), immediately Dispose it, and then do the assignment. The "font description" part of the Font remains quasi-valid even after Disposal, and that's all that's really needed for the Control.Font property.
Related
Today my intstructor, where I'm intern, said I should use
HImage hi = null;
HOperatorSet.GenEmptyObject(out hi);
hi.Dispose();
hi = f.GrabImageAsync(-1.0);
Instead of
HImage hi = null;
hi = f.GrabImageAsync(-1.0);
Prototypes of used functions as follows
void HOperatorSet.GenEmptyObj(out HObject emptyObject);
HImage HFramegrabber.GrabImageAsync(double maxDelay);
I respect my instructor ,but I don't see any meaningful explanation at creating and disposing an object before calling hi = f.GrabImageAsync(-1.0); as that functions returns an instance of that object and therefore no need for Generating and Disposing object first, at least in my opinion.
So anyone can clarify if it is really needed or not. Thank you in advance.
I agree with you. Generally there is no use in creating and immediately disposing a variable.
As far as we can see from the code, HOperatorSet.GenEmptyObject doesn't interact with your f variable, so there would be no meaning in calling that method.
Also, there is no point in setting HImage hi to null, since that is probably the default already and it is set using the out parameter.
So my bet would be on:
HImage hi = f.GrabImageAsync(-1.0);
Most of the time Dispose() is called to release all managed resources that no longer in need. So let's assume that HOperatorSet.GenEmptyObject(out hi) method opens FileStream and saves reference to some field in new HImage instance. Later in code you would like to do other operation with this HImage instance and no longer need this FileStream or any other resources. It's a good moment to call hi.Dispose() that closes it before you proceed with doing anything else. But in any other case your instructor is misleading you.
There are a few classes in WinForms which have multiple purposes, some of which require resources and some of which don't. The one I'm most familiar with is Font. A Font instance encapsulates a combination of font settings as well as a GDI handle to a GDI font resource. The Font property setter of most WinForms controls will cause the controls to copy of the settings from the passed-in font object and store a copy of the passed in Font reference so that it may be returned by a call to the property getter, but will not cause the controls to actually use the passed-in font for drawing. Since the settings can be read from a Font object even after is is disposed, it is in fact possible to create and dispose Font objects when setting controls' Font properties; in some cases it may arguably be a reasonable least-of-evils approach:
If Font objects are created and abandoned without disposal, that will usually not cause too much of a GDI resource drain, but such wishful thinking doesn't represent good design.
A policy of calling Dispose on a control's old value of Font before setting a new value will require that every control own its own separate Font object, which will then encapsulate a resource the control will never use. The one advantage is that code which reads a control's Font property will be able to draw using that Font object directly.
Having controls hold references to font objects that are already disposed will make it possible for multiple controls to safely share the same font object, and will consume fewer GDI resources than either of the other approaches. The one limitation is that any code which reads a control's Font property and wants to draw with that font will have to use it to construct a new Font object for the purpose (and probably dispose of it after use).
IMHO, the fact that disposing Font objects immediately on creation is a useful pattern suggests that the Framework should have included separate types for the purposes of describing fonts (the purpose of a control's Font property) and encapsulating GDI font objects (the purpose of the Font parameter to string-drawing methods). If the latter type had included Dispose and the former type not, there would have been no question about how to use each. Since the Font type exists, however, along with code that uses it for those disjoint purposes, the eager-dispose pattern may be a reasonable least-of-evils approach.
I'm not sure that approach represents what's going on in your instructor's example since I'm not familiar with the types involved. It may be that the object returned by GenEmptyObject doesn't actually allocate any resources and its Dispose method does nothing (and stating that the particular object may be safely abandoned may be better than calling Dispose prematurely) but if the object acquires resources which won't be needed for its intended use, early disposal might possibly be appropriate if commented.
If i have public method that returns a reference type value, which is private field in the current class, do i need to return a copy of it? In my case i need to return List, but this method is called very often and my list holds ~100 items. The point is that if i return the same variable, everybody can modify it, but if i return a copy, the performance will degrade. In my case im trying to generate sudoku table, which is not fast procedure.
Internal class SudokuTable holds the values with their possible values. Public class SudokuGame handles UI requests and generates/solves SudokuTable. Is it good practice to chose performance instead OOP principles? If someone wants to make another library using my SudokuTable class, he wont be aware that he can brake its state with modifying the List that it returns.
Performance and object-oriented programming are not mutually exclusive - your code can be object-oriented and perform badly, etc.
In the case you state here I don't think it would be wise to allow external parts edit the internal state of a thing, so I would return an array or ReadOnlyCollection of the entries (it could be a potential possibility to use an ObservableCollection and monitor for tampering out-of-bounds, and 'handling' that accordingly (say, with an exception or something) - unsure how desirable this would be).
From there, you might consider how you expose access to these entries, trying to minimise the need for callers to get the full collection when all they need is to look up and return a specific one.
It's worth noting that an uneditable collection doesn't necessarily mean the state cannot be altered, either; if the entries are represented by a reference type rather than a value type then returning an entry leaves that open to tampering (potentially, depending on the class definition), so you might be better off with structs for the entry types.
At length, this, without a concrete example of where you're having problems, is a bit subjective and theoretical at the moment. Have you tried restricting the collection? And if so, how was the performance? Where were the issues? And so on.
Just short question, if you have a class with just one 1 property, and lots of (non static) methods, does an entirely new object get stored every time you say 'new object()', or just the property, and the methods in some 'common' memory space so the same Type can reference to that?
Thus, is having a large class always performing worse than a small class in terms of instantiation time?
Memory allocation may prove to be time consuming indeed.
Still, I believe a cleaner, more obvious measurement of resource consumption would be occupied space not instantiation time.
As you have stated yourself already, it is the case that methods,
static or not, occupy memory space just once. The this reference is just a hidden parameter, which gets sent from caller to called code just like any other parameter and in the end, all methods are just plain ol' functions (or routines).
In a simplistic way of putting it, so do all static fields.
Don't think about properties. They are just high level wrappers for methods which in the end access fields.
Instance fields are what occupies space, per instance.
But there are other things, like runtime type information which get allocated also.
In short, your assumption is correct.
EDIT
Just as a recap:
If by "large class" you mean a class which defines a lot of methods, then no, instantiation time will not be affected.
On the other hand, if by that term, you mean a class which defines a lot of instance fields, then yeah, instantiation time will be affected.
Although this is not my happy place (I know almost nothing of how good ol' malloc actually manages to defragment memory) thinking that allocating a lot of memory would take a longer time is in a strange way I can't put my finger on, like saying that
"adding the numbers 1024 and 2048 takes a bit longer than adding the numbers 3 and 4"
(given all 4 numbers are stored in variables of same numerical type).
So I would worry more about memory consumption. I'm sure time is somehow affected too, but maybe logarithmically.
Methods are shared. All other things being equal, instantiating a class with many methods has pretty much the same cost as instantiating one with few. It's their non-static fields and the amount of work performed by the constructor (and some other minor factors) that determine creation cost.
Instance fields are the only thing stored in the object itself. Methods are stored in the type, which means that they only exist in one place.
In fact, instance methods are just syntactic sugar (at the IL level) for static methods that accept an instance as a parameter.
I think you will find the information you need (and probably more) here . The code of the instance methods will be shared.
I would like to be able to:
compare Word Interop COM proxies on a "reference equality" basis; and
map from a specific object (say a paragraph) to the collection it comes from, OR at least
determine whether two paragraphs are from the same section and which one comes relatively before the previous one
Why do I want to do this? I am trying to build a Word Add-In that acts similarly to a spell-checker in the sense that it runs in the background (by background I mean by regularly stealing time from the main Word thread using SendMessage) and scans the document for certain text "tokens". I want to be able to keep a collection of the tokens around and update them as the document changes. A specific example of this is if the user edits a given paragraph, I want to rescan the paragraph and update my data structure which points to that paragraph. If there is no way to map between the paragraph the user edited in (i.e. the paragraph where the start of the selection range is) and a paragraph that I have "stored" in a data structure, I can't do this.
Example Code for item #1, above
If I write the following VBA code:
Dim Para1 As Paragraph
Dim Para2a As Paragraph
Dim Para2b As Paragraph
Set Para1 = ActiveDocument.Paragraphs(1)
Set Para2a = Para1.Next
Set Para2b = Para1.Next.Next.Previous
If Para2a Is Para2b Then
Debug.Print ("Para2a Is Para2b")
Else
Debug.Print ("Para2a Is Not Para2b")
End If
Then I am getting the output:
"Para2a Is Not Para2b"
Which is perhaps physically true (different COM proxies) but not logically true. I need to be able to compare those paragraphs and determine if they are logically the same underlying paragraph.
(I am planning to write the add-in in C#, but the above VBA code demonstrates the kind of problem I need to overcome before doing too much coding).
For items 2 and 3 above, hopefully they will be self-explanatory. Say I have a paragraph (interop proxy) reference. I want to figure out "where" it is in the document. Does it belong to Section 1? Is it in a footer? Without this ability, all I can reasonably do to obtain an idea of where things come from is rescan the entire document every time it changes, which is of course absurdly inefficient and won't be timely enough for the app user.
Any thoughts greatly appreciated! I'm happy to post additional information as needed.
Navigating the particulars of reference equality in the context of COM Interop is always an interesting exercise.
I wouldn't be privy to the implementation details of the Paragraph.Next() and Paragraph.Previous() methods, however the behavior they exhibit is very similar to how COM-based collections act in general in regards to Runtime Callable Wrapper creation.
Typically, if possible, the framework avoids creating new RCW instances in response to additional references being made to COM objects that already have an RCW initialized and assigned. If an RCW already exists for a particular pointer to IUnknown, an internal reference count maintained by that RCW is incremented, and then the RCW is returned. This allows the framework to avoid incrementing the actual COM object's reference count (AddRef).
COM-based collections, which are COM objects that have managed representations implementing IEnumerable, seem to generate a new RCW each time an item is accessed, even if that item has already been accessed during the session.
For example:
Word.Document document = Application.ActiveDocument;
Paragraphs paragraphs = document.Paragraphs;
Paragraph first = paragraphs[1];
Paragraph second = paragraphs[1];
bool thisIsFalse = (first == second);
If you want to do any sort of "reference equality" checking, you need to escape from the COM based collection, specifically in your case: the Paragraphs object. You can do this simply by grabbing its kids and storing them in your own, purely managed and predictable collection, like so:
List<Paragraph> niceParagraphs = paragraphs.Cast<Paragraph>().ToList();
Although using LINQ with COM Interop may look a bit scary (if it doesn't to you...it really should!) I'm fairly certain the above code is safe and will not leave any dangling references out there, or anything else nasty. I have not tested the above code exhaustively, however.
Don't forget to properly release those resources when you are done with them, at least if your requirements require that level of prudence.
In my case I have 2D ArrayList full of objects that have data which is used when drawing horizontal lines, vertical lines and filled rectangles. In different cases the amount of objects is different and the image has a different amount of drawn lines and rectangles. But the image needs to be redrawn sometimes. The more stuff there is to redraw, the stronger the flashes on the screen (I hope you can figure out what I mean with "flashes").
I have already tried double buffering, but I don't think I'm doing it right- the type of the flashes only changes... But that's not the current case.
I have read that it's easy to add and remove elements (no matter the type) anywhere from the ArrayList, but the access to them is hard. I have also read that the List performs better that the ArrayList (does that mean that the program will require less resources fro the computer?), but it's only easy to add and remove elements from the end. But I'm not sure if the Array's performance is the fastest. And this is making me think that the flashes can become weaker if I change the ArrayList with an Array or List.
It won't be a problem in my case because all the elements that I store in the ArrayList are form the same class.
My question is: Can I weaken the flashes if I replace the ArrayList with an Array or List?
OK, two problems here. The ArrayList vs. List question has no effect on "flashing", since the difference in performance is small. If your list items are all of the same type or if they all derive from a common base type other than object or if they all implement a common interface, then List<T> is the better choice. This is because less castings or even boxings/unboxings are involved. In addition, it will be easier to access your items.
Flashing: Do all your drawing in a paint-event method (of your form or of some control). Then call the Invalidate method of this form or control. Don't draw "directly". As an improvement, you can pass a rectangle structure to Invalidate, telling which part has to be redrawn. In the paint method, you can then check e.ClipRectangle, which tells you which part has to be redrawn. This gives you the opportunity to make some improvements here. However, be aware of the fact, that the Windows OS itself can trigger an Invalidate, which results in arbitrary ClipRectangles.
Comparing drawing performance with reading from ArrayList performance, you can't solve flickering problem by using another data container. So, alternative container of ArrayList is not the answer. You need to use some other methods like;
Using SDL, DirectX, OpenGL like graphics library.
Drawing to a bitmap buffer and showing the bitmap after it is completed (similar to double buffering but sometimes it works better).
Subclassing some components and overriding some methods like background drawing.
There are even more methods but the answer of your question is definitely not much to do with ArrayList.
You should use a List<T> instead of ArrayList, just to get rid of the unnecessary casting when you read objects from the list. However, the performance gain from that is so small compared to drawing graphics that it won't have any noticable effect on your update problem.
You could consider drawing your graphics to a bitmap, then draw the bitmap when you need to update the screen.
A List<T> and an ArrayList behave the same when it comes to adding and removing elements; it's cheap to add or remove elements at the end of the list, but more expensive to insert or remove elements at the beginning of the list.
An array is the fastest of the lists, and both List<T> and ArrayList uses arrays to store its elements internally. However, you can't resize an array so you might still want to use a List<T> as it does the work of allocating arrays as needed and keeps track of how much of the array is used.
To fix the "flashes", you need to enable double-buffering.
You should not use ArrayList because it encourages mistakes and/or poor design.
You should not have lists that contain multiple types of objects.
Instead, you should use List<T>, perhaps with a polymorphic base class.