Prev: Anybody using VBScript.RegExp 5.5 ?
Next: And now the news from VODC Germany
From: nodenose on 1 Nov 2006 06:22
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

From: Geoff on 1 Nov 2006 07:23
Hello ????

Essentially I don't think many people will agree with you. We do know
for a fact that the IDE was measurably slower with each release of 2.7
but not the compiled apps. In particular we have been dealing with email
clients and the like that manage very large strings (10MB etc) and did
not notice any change in application performance that we could measure.

But that is not to say that you don't have some code construct that
compiler changes have brought up issues for you. The issue is to try to
determine what factors that might be affecting you and not others.
(There were many debates on this very subject on the VOPS forum at the
time but they were inconclusive.)

I think you need to profile your app and find out what sections of code
cause undue GC activity or cleanup. Perhaps you aren't releasing large
objects, arrays or strings? Perhaps you have array or string handling
mechanisms that could be modified? Perhaps you are doing deliberate
calls to the GC that should now be removed? Could you find out where the
heaviest activity is and show us some of this code?

The only comfort I can offer is that most of us do not suffer exe
performance issues with 2.7 so I am hopeful there is a solution for you.

Geoff

From: nodenose on 1 Nov 2006 08:02

Geoff schrieb:

> Hello ????
>
> Essentially I don't think many people will agree with you. We do know
> for a fact that the IDE was measurably slower with each release of 2.7
> but not the compiled apps
>
> But that is not to say that you don't have some code construct that
> compiler changes have brought up issues for you. The issue is to try to
> determine what factors that might be affecting you and not others.
>
> I think you need to profile your app and find out what sections of code
> cause undue GC activity or cleanup. Perhaps you aren't releasing large
> objects, arrays or strings? Perhaps you have array or string handling
> mechanisms that could be modified? Perhaps you are doing deliberate
> calls to the GC that should now be removed? Could you find out where the
> heaviest activity is and show us some of this code?
>
> The only comfort I can offer is that most of us do not suffer exe
> performance issues with 2.7 so I am hopeful there is a solution for you.
>
> Geoff

Sorry but i've you dont have problems that is no evidence that there is
no problem. I know that a can write VO code that do not have this
problems. e.g we have two variants of db-Import and export. One uses
plain SQL-Statements the other prepared Statements with dynamic
columnbuffers bind to Columns. The last one has no problem cause it
does not need the GC. The first one triggers the GC a lot. But I think
the benefit of VO (in the early Days) was that we don't have to care
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.

We don't call the GC.

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.

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
war.


I think that your app is not compareable to our so please dont compare!

From: Ginny Caughey on 1 Nov 2006 08:09
I know that Geoff's posts can sometimes be irritating, but I think his
message might be more or less right this time. The GC is apparently slower
in 2.7 (although most apps don't notice it including mine) and that is a
side effect of having it actually work right and fixing some of its long
standing bugs. Since the new performance is unacceptable for your app, I
think the best solution really is to try to optimize it even more to avoid
the GC if possible. For example, if you're doing a lot of math computation
with Floats but not calling a lot of functions/methods using those Floats,
you might get better performance using Real8 instead. Can you pin down
specifically where it's slower? That might be a starting point. But I don't
think turning off the GC is going to be a satisfactory strategy for
production apps.

--
Ginny


<nodenose(a)Web.de> wrote in message
news:1162386160.577147.321530(a)m7g2000cwm.googlegroups.com...
>
> Geoff schrieb:
>
>> Hello ????
>>
>> Essentially I don't think many people will agree with you. We do know
>> for a fact that the IDE was measurably slower with each release of 2.7
>> but not the compiled apps
>>
>> But that is not to say that you don't have some code construct that
>> compiler changes have brought up issues for you. The issue is to try to
>> determine what factors that might be affecting you and not others.
>>
>> I think you need to profile your app and find out what sections of code
>> cause undue GC activity or cleanup. Perhaps you aren't releasing large
>> objects, arrays or strings? Perhaps you have array or string handling
>> mechanisms that could be modified? Perhaps you are doing deliberate
>> calls to the GC that should now be removed? Could you find out where the
>> heaviest activity is and show us some of this code?
>>
>> The only comfort I can offer is that most of us do not suffer exe
>> performance issues with 2.7 so I am hopeful there is a solution for you.
>>
>> Geoff
>
> Sorry but i've you dont have problems that is no evidence that there is
> no problem. I know that a can write VO code that do not have this
> problems. e.g we have two variants of db-Import and export. One uses
> plain SQL-Statements the other prepared Statements with dynamic
> columnbuffers bind to Columns. The last one has no problem cause it
> does not need the GC. The first one triggers the GC a lot. But I think
> the benefit of VO (in the early Days) was that we don't have to care
> 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.
>
> We don't call the GC.
>
> 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.
>
> 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
> war.
>
>
> I think that your app is not compareable to our so please dont compare!
>


From: Armin Back on 1 Nov 2006 08:16
Hi ???

> 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?

did you try to set the initial available amount of dynamic memory in your
start method to a greater value, for instance setting DynSize(100)?

HTH

Armin


 |  Next  |  Last
Pages: 1 2 3 4
Prev: Anybody using VBScript.RegExp 5.5 ?
Next: And now the news from VODC Germany