Vo 2.7 Garbage Collector
in [Visual Objects]
|
From: Geoff on 3 Nov 2006 18:50 Georg. Those issues surrounding the core of VO have been known or some time. They were even argued over in the VOPS forum when the forum first started and the early versions of 2.7 released. Some gents were even able to provide definitive cases of where the GC and memory management could be optimised for the end application's benefit. But your primary premise is correct: changes in the 2.7 versions did cause some coding constructs some problems. Either Robert was unable to reverse the effects or he wasn't given a budget to do so. It is also reasonably clear that 2.8 probably also does not address these issues so the only advice I can offer is that you raise the matter directly with GrafXSoft. You will note that matters like these never attract any response from the folks that matter... Regards, Geoff > > Hello,, > > we do a lot of optimisation in our programm. And belive me that i know > what we can optimize. But the problem is that our VO will run out in a > few years. Some sooner some later. I is not economic if i rewrite that > code to get the golden code award. > > Keep in mind that our app is an an dm-system. Some things have to be > cached to achieve a aceptable performance. We do a lot of in this > direction. Even filter as much we can on DB. The other big thing is ouR > cache for the business objects. We have implemented something like an > singleton pattern for them. So we can be absolut shure that for each > DB-Record is only one business object in memory. And the best is that > this works together with the gc. If we no longer need the object it get > kicked by the GC as other objects. If we load that object again we can > detect if it is still in memory or not. > > But beware the problem is not the amout ob objects in memory. As you > can see in the logs the GC is still fast if you have a lot of them. The > problem is the frequency he is called. As you can see this is directly > influenced by the amout of prealloceted pages. > > I would be happy if someone of the VODEV-Team could confirm this guess. > If this is the real problem we can find a way to advance VO in that > aspect. This type of problems is not new in computer science. If you > take a closer look to your database server you can find the same > problem. If an tablespace has to be extended the DBMS reallocate more > space than needed. This extend can be configured. This is good because > customer A has only a small DB and needs only one megabyte each year. > The customer B needs one megabyte each hour. So in this example it > would be smarter for admin A to extend the DB in greater quantities to > reduce the expensive expansions. > > > best regards...
From: Robert van der Hulst on 4 Nov 2006 03:17 Georg, On 3 Nov 2006, at 02:12:29 [GMT -0800] (which was 11:12 where I live) you wrote about: 'Vo 2.7 Garbage Collector' > But beware the problem is not the amout ob objects in memory. As you > can see in the logs the GC is still fast if you have a lot of them. The > problem is the frequency he is called. As you can see this is directly > influenced by the amout of prealloceted pages. > I would be happy if someone of the VODEV-Team could confirm this guess. > If this is the real problem we can find a way to advance VO in that > aspect. This type of problems is not new in computer science. If you > take a closer look to your database server you can find the same > problem. If an tablespace has to be extended the DBMS reallocate more > space than needed. This extend can be configured. This is good because > customer A has only a small DB and needs only one megabyte each year. > The customer B needs one megabyte each hour. So in this example it > would be smarter for admin A to extend the DB in greater quantities to > reduce the expensive expansions. From what I have read in this thread (I have not read all the replies from OZ because these are on my ignore list) I can conclude the following: - the speed difference between your 2.5 app and the the 2.7 app are the result of the amount of memory that gets allocated at startup time. VO 2.5 relied on a setting in the registry. VO 2.7 does not do that anymore but expects you to set the amount of memory your app needs in your code (SetMaxDynSize). This may seem like a step back but it isn't imho. Consider what would happen with your VO 2.5 app if your customer installed another VO app and the developer of that app (for example a colleague from your company) overwrote the registry setting with a lower number. In VO 2.5 your app would suffer performance problems and you would have no idea why. In VO 2.7 you don't have that negative effect because the setting is controlled in your code If you think the GC is called too often you should preallocate pages of dyn memory by calling DynSize(). For example if you know that at startup you are allocating 4 Mb of dynamic memory, you could set the dynsize in advance to 4 Mb/64 Kb = 64 pages. FInally if you are allocating a lot of static objects that existing during the whole lifetime of your app, you should consider to move them out of dynamic memory into static memory. You can use CreateInstanceStatic() to create these objects (and must use FreeStaticObject to release them when you are done with them). -- Robert van der Hulst AKA Mr. Data Vo2Jet & Vo2Ado Support VO Development Team www.heliks.nl
From: Geoff on 4 Nov 2006 05:24 > From what I have read in this thread (I have not read all the replies from > OZ because these are on my ignore list) I can conclude the following: That's a shame <g>. Otherwise you would have seen me refer him to your VooDoo paper where you discuss exactly these matters. His problem is not in the volume of memory (he already stated that he allocated enough), it was in the amount of work the GC appeared to be doing. It isn't a startup issue. This change in GC behaviour happened in a very early 2.7 version - before 2740. Geoff
First
|
Prev
|
Pages: 1 2 3 4 Prev: Anybody using VBScript.RegExp 5.5 ? Next: And now the news from VODC Germany |