Introduction
This article introduces memoization and a quick usage of WeakReference
.
It's not a bad typo ; the term memoization is a real word. You can read this article in wiki.
Background
Memoization is a concept that appeared in 1991 around general studies of parser technologies. But the underlying concept of this term was already known by every programmer in games development; the idea that a game needs to be pre-addressed and all computations which had taken a longer time as needed if it was computed on the fly, were memoized.
To memoize an object is just the things that if you give the same parameters in a function call, and the function computes for a long time, you should memorize just the result and suppress the time consuming to recompute the result with same parameters.
The problems are:
- What kind of parameters will you accurately memoize?
- What are kind of algorithms useful to memoize?
Is memoization like the term "caching"? I answer that it is not.
Using WeakReference
Next in .NET, and first in Java, a weak reference is just like to give a chance to the computer's background work that it keeps the result for a short or a long time; and, if the target object has reclaimed by garbage collection, it means you need to compute again.
There is a clear definition of what is WeakReference
and its usability:
Then, another way is to keep data by serialization. Also, serialization and memoization are similar concepts.
But, unfortunately, serialization is a process which takes, for instance, a relative memory size, time consuming and efforts code (and tests and maintaining, etc.). As you could serialize your data into a simple JSON string
and hold this in an isolated storage (for example), it's a little bit too much effort for any data model which does not size less than 1Mo.
The relative effort to code these needs is not very interesting, if you just want something to keep your objects closely.
A Little Basis Starter
First, create a new AppDomain
(the code below works with .NET v2):
AppDomainSetup ads = new AppDomainSetup();
ads.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory;
ads.ConfigurationFile = AppDomain.CurrentDomain.BaseDirectory + "createAppDomain.exe.config";
ads.ApplicationName = "InnerApp";
Evidence ade = new Evidence();
ade.AddHost(new Zone(SecurityZone.MyComputer));
this._dom = AppDomain.CreateDomain("innerApp", ade, ads);
You can create a new Thread
in this new AppDomain
. And, in order to communicate between domains, you are using these methods:
object obj = this._dom.GetData("name");
AppDomain.CurrentDomain.SetData("name", obj);
While you are loading a big file, a big data from SQL or from an XML file, use the inner domain to handle it.
When you select your data and you ask the inner domain to restore some of them, deserialize and marshall data to the primary domain. Since data is cached by the inner domain, you create a WeakReference
of the deserialized object from the primary domain.
While you want to post data between domains, use the callback
delegate:
CrossAppDomainDelegate cross = new CrossAppDomainDelegate(() => {});
this._dom.DoCallback(cross);
And when you leave the object left, the WeakReference
does that the garbage collector reclaims this object.
Finally, if you modify the content of the object, you may pass the serialized version to the inner domain.
The inner domain will replace, insert, delete any kind of changes into your database or into your file or else into your XML file, by a direct update.
Points of Interest
To the resulting implementation, you have the ability to map your objects for a temporary time line, life cycle even when you are canceling your changes. Each windows form (old & WPF) which binds to your object, are designed to accept any changes of the object or reject immediately all your change with no overrun.
In general, you keep objects in a list to give the ability to access them at any time. If you centralize your objects, you are taking advantage of a rough conception.
It will be interesting to leave these standard management cycle to something you can get your objects because they reside where you need them; for example, just into the methods to add, find, search, modify, delete objects regarding the object type you need to access.
I heard about memoization one week ago. In my opinion, it seems to be a great idea.
But, implementation and usage are not common.
To play with memoization, a big modelization effort is needed to reduce time consumption. And, usage of WeakReference
is not the same objective but to enable a fast transactional storage.
History
First version of this article. Share it or discuss if you have any questions, tips or ideas.
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.