Prev: Anybody using VBScript.RegExp 5.5 ?
Next: And now the news from VODC Germany
From: Malcolm Gray on 1 Nov 2006 08:39
> Here the used linker options (not optimized):
> ---------------------------------------------------------------
> [VOLink]
> MAP=0
> BinarySize=0x6000000
> text=0x6000000 // 48 Mb
> data=0x6000000 // 64 Mb
> rdata=0x2000 // 4 Kb
> bss=0x2000 // 4 Kb
> edata=0x100000 // 16 Mb
> idata=0x200000 // 2 Mb
> reloc=0x2000000 // 32 Mb
> rsrc=0x2000000 // 16 Mb -> 32mB
> StackSize=0x4000000 // 64 MB
> TempAtomTabSize=0x8000000

Are you modifying the amount of dynamic memory (registry keys in VO25,
function calls in Vo27)?

From: nodenose on 1 Nov 2006 09:02

Malcolm Gray schrieb:

> > Here the used linker options (not optimized):
> > ---------------------------------------------------------------
> > [VOLink]
> > MAP=0
> > BinarySize=0x6000000
> > text=0x6000000 // 48 Mb
> > data=0x6000000 // 64 Mb
> > rdata=0x2000 // 4 Kb
> > bss=0x2000 // 4 Kb
> > edata=0x100000 // 16 Mb
> > idata=0x200000 // 2 Mb
> > reloc=0x2000000 // 32 Mb
> > rsrc=0x2000000 // 16 Mb -> 32mB
> > StackSize=0x4000000 // 64 MB
> > TempAtomTabSize=0x8000000
>
> Are you modifying the amount of dynamic memory (registry keys in VO25,
> function calls in Vo27)?

Yes we do. Ordinary we don't need. But out app is managing political
sessions. And some of our customers have sessions with 100 people and
40 points on their agenda. And the absolut crazy customers wanne know
wich people was present at wich point.
so we have to load a lot objects from the DB ( 100 + 30 + ( 100 * 40 )
= 4140. And in this moments we need to play with this switches.

From: Otto Christiaanse on 1 Nov 2006 15:17

> We don't call the GC.

You don't have to: VO will do it for you.

> I've done al lot of optimization in this way. And always the best
> solution was to throw away naive string processing an replace it with
> own managed memory. Not a big deal if we talk about something like an
> RTF-Dokument generator, SQL-Data-Fetching or something similar. But
> this can not be the solution for the entire App.


In one of our tools we generate VO source code (20Mb) based on a
datadictionary stored in a database.

Initialy we did the source building by string concat.
Also there are lots of concats in making the queries.

But as you state, the GC is going wild over that, because VO adresses every
time a new memory block for the result of a concat.
As you also suggested, we did switch to a stringbuilder object (thanks
Anthony!), and together with good initial dynsize and max dyn size settings
(and a few other things) we got an enormous performance boost.

And yes, it is an investment to make the switch...

But I would give it a try.

The fast way would be to try Armin's suggestion first. MAYBE there is gain
without pain... :)

Best regards,
Otto
From: Geoff on 1 Nov 2006 16:17
Hi Nameless.

Aren't you taking this the wrong way?
We're here to offer you help - you asked, remember?

You can write apps in many different ways and by the sound of things,
you rely on a lot of dynamic object generation. Let me repeat my main
comment: most people do not experience a problem with GC performance
impacting on their applications.

All I'm asking is that you show us some of that code style where
profiling indicates high GC loads and I am certain we could offer you
different ways to write your code. In many respects, changes in the
compiler in 2.7 forced the coder to adapt to better programming
practices. That such adaptation causes some pain is not unexpected.
We're here to assist if you will let us.

> about that. I can not understand how you try to downplay the fact, that
> the same code is 100% slower than under Vo 2.6. And that the GC needs
> more than 50% of the entire processing time of our app.

I'm not. But you also have to accept that this is extremely unusual.
This means you should accept the fact that you are doing something
different.

> I don't like those VO-Thread with hundreds of Post saying "hey its you
> fault. rewrite your code." I don't whant another unproductive VO-flame

But no-one is starting one! Equally you need to consider the possibility
that there might be a better way to write certain parts of your
application. No-one is suggesting everything. Why shoot us first before
giving us a try?

Geoff


From: Phil Mermod on 2 Nov 2006 03:29
Hi,

We had the same kind od problem when switching to 2.7 as we have a
strong maths module and processes with arrays. Now we use and adapt
DynInfoMax() and Dynsize() which help the GC to be called less than
originaly and Collectcount() to check the frequency of collect by the GC.

HTH,

--
Phil Mermod
Crystal Reports Library for Visual Objects
http://www.pkl.ch/dev/

nodenose(a)Web.de wrote:
> Hello Folks,
>
> I've a huge Problem with Vo 2.7b we have two Applications converted to
> Vo 2.7.2.2735 (b) but there is a huge performance problem. The
> application is much slower than under Vo 2.6.0.1151(b). I've checked
> the compiler settings and tried to sync them to those used under Vo
> 2.6. But this does not help. After some reviews i found out, that the
> GC is a huge factor on that problem.
>
> Here is a GC-profilelog i've made:
>
> 0000 0.00000000 GC Time: 00000032ms LRun: 00000016ms CCnt: 00100
> 0001 0.17891040 GC Time: 00000032ms LRun: 00000016ms CCnt: 00200
> 0002 0.35827491 GC Time: 00000064ms LRun: 00000016ms CCnt: 00300
> 0003 0.53739405 GC Time: 00000064ms LRun: 00000016ms CCnt: 00400
> 0004 0.71668613 GC Time: 00000064ms LRun: 00000016ms CCnt: 00500
> 0005 0.89759725 GC Time: 00000064ms LRun: 00000016ms CCnt: 00600
> 0006 1.07764328 GC Time: 00000064ms LRun: 00000016ms CCnt: 00700
> 0007 1.25755858 GC Time: 00000064ms LRun: 00000016ms CCnt: 00800
> 0008 1.43635201 GC Time: 00000064ms LRun: 00000016ms CCnt: 00900
> 0009 1.61603081 GC Time: 00000064ms LRun: 00000016ms CCnt: 01000
> 0010 1.79720294 GC Time: 00000079ms LRun: 00000016ms CCnt: 01100
> 0011 2.39255452 GC Time: 00000391ms LRun: 00000016ms CCnt: 01200
> 0012 3.68954158 GC Time: 00001425ms LRun: 00000016ms CCnt: 01300
> 0013 5.79480124 GC Time: 00003254ms LRun: 00000032ms CCnt: 01400
> 0014 9.73104382 GC Time: 00005475ms LRun: 00000032ms CCnt: 01500
> 0015 14.87337399 GC Time: 00007974ms LRun: 00000032ms CCnt: 01600
> 0016 18.60230446 GC Time: 00010769ms LRun: 00000032ms CCnt: 01700
>
> You can see that from 18,6 seconds over ten seconds are only for
> garbage....
> I don't have compareable results for Vo 2.5 but if i lock the GC the
> performace is better than under 2.5 So i think the main factor is the
> paranoid GC under Vo 2.7b.
>
> The main Reason why we make the step to 2.7 is that we are able to
> debug even large projects.But only with some undocumented linker
> options.
>
> Is there an switch to paralyze the GC so that he behave like in Vo 2.6?
> Can i apply the linker options to VO 2.6?
>
>
> Here the used linker options (not optimized):
> ---------------------------------------------------------------
> [VOLink]
> MAP=0
> BinarySize=0x6000000
> text=0x6000000 // 48 Mb
> data=0x6000000 // 64 Mb
> rdata=0x2000 // 4 Kb
> bss=0x2000 // 4 Kb
> edata=0x100000 // 16 Mb
> idata=0x200000 // 2 Mb
> reloc=0x2000000 // 32 Mb
> rsrc=0x2000000 // 16 Mb -> 32mB
> StackSize=0x4000000 // 64 MB
> TempAtomTabSize=0x8000000
>
>
> Here the code i used for profiling the GC:
> -----------------------------------------------------------
>
>
> function OnGCStart() as void pascal
>
> dwGCStart := GetTickCount()
> dwGCCount += 1
> // OutputDebugString( pszGCMsgStart )
> return
>
>
> function OnGCStop() as void pascal
>
> local dwTemp as dword
>
> dwGCStop := GetTickCount()
> dwTemp := dwGCStop - dwGCStart
> dwGCTime += dwTemp
>
> if dwGCLongestRun < dwTemp
> dwGCLongestRun := dwTemp
> end if
>
> // OutputDebugString( pszGCMsgStop )
>
> if dwGCCount % 100 == 0
> OutputDebugString( String2Psz( ;
> "GC Time: " + StrZero( dwGCTime,8,0)+ ;
> "ms LRun: " + StrZero( dwGCLongestRun,8,0 )+;
> "ms CCnt: " + StrZero( dwGCCount,8,0)))
> end if
> return
>
>
> function MonitorGC( lStart as logic ) as void pascal
>
> if pszGCMsgStart == NULL_PSZ
> pszGCMsgStart := StringAlloc( "GC start" )
> endif
>
> if pszGCMsgStop == NULL_PSZ
> pszGCMsgStop := StringAlloc( "GC stop" )
> endif
>
> if lStart
> _RegCollNotifyStart( @OnGCStart(), true )
> _RegCollNotifyEnd( @OnGCStop(), true )
> else
> _RegCollNotifyStart( @OnGCStart(), false )
> _RegCollNotifyEnd( @OnGCStop(), false )
>
> MemFree( pszGCMsgStart )
> MemFree( pszGCMsgStop )
> pszGCMsgStart := NULL_PSZ
> pszGCMsgStop := NULL_PSZ
> end if
>
> static global dwGCStart as dword
> static global dwGCStop as dword
> static global dwGCTime as dword
> static global dwGCCount as dword
> static global dwGCLongestRun as dword
> static global pszGCMsgStart as psz
> static global pszGCMsgStop as psz
>
>
> I started the log inside the Start method of my App. Even if i output
> the performance-log in bigger intervals the result does not change. So
> i think the log does not have a huge impact.
>
>
>
> best regards
>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Anybody using VBScript.RegExp 5.5 ?
Next: And now the news from VODC Germany