TeamB, Borland, admit obvious
From: Hrvoje Brozovic (a.b_at_c.de)
Date: 03/05/04
- Next message: David Clegg: "Re: Database Independance"
- Previous message: David Clegg: "Re: Database Independance"
- Next in thread: K. Sallee: "Re: TeamB, Borland, admit obvious"
- Reply: K. Sallee: "Re: TeamB, Borland, admit obvious"
- Reply: John Herbster \(TeamB\): "Re: TeamB, Borland, admit obvious"
- Maybe reply: Nick Hodges (TeamB): "Re: TeamB, Borland, admit obvious"
- Reply: Rudy Velthuis (TeamB): "Re: TeamB, Borland, admit obvious"
- Maybe reply: Rudy Velthuis (TeamB): "Re: TeamB, Borland, admit obvious"
- Reply: Barry Kelly: "Re: TeamB, Borland, admit obvious"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 5 Mar 2004 13:10:56 +0100
This was discussed before, but just for a record.
It is not something we can just go over and forget.
Exhibit A: From Delphi 7 help.
Using the plus (+) operator has the same effect on two
strings as using the Concat function:
S := 'ABC' + 'DEF';
Tip: The plus operator is faster than Concat.
MY NOTE: Borland encourages developers to use it.
Exhibit B: From Delphi 7 help
For a long-string or dynamic-array variable, SetLength reallocates
the string or array referenced by S to the given length.
Existing characters in the string or elements in the array are preserved,
but the content of newly allocated space is undefined
Following a call to SetLength, S is guaranteed to reference a unique string.
MY NOTE: After SetLength, you have flat mem for your string
Exhibit C: From Delphi CPU window
s1 := s2 + s3 calls LStrCat3
s1 := s1 + s2 calls LStrCat
MY NOTE: Obviously s1 += s2 is treated as special case by Borland.
Exhibit D: From getMem.inc, SysReallocMem
if ResizeInPlace(p, size) then
result := p
else begin
n := SysGetMem(size);
MY NOTE: Borland always tries to resize in place,
and that has pretty good chance of success if you prepend batch
of concats with SetLength( s_str, i_expected_final_size )
Exhibit E: From MSDN
When performing repeated concatenations of the type:
For I = 1 To N
Dest = Dest & Source
Next N
the length of time increases proportionally to N-squared. Therefore,
1000 iterations will take about 100 times longer than 100 iterations.
This is because Visual Basic does not just add the Source characters
to the end of the Dest string; it also performs the following operations:
1 Allocates temporary memory large enough to hold the result.
2 Copies Dest to the start of the temporary area.
3 Copies Source to the end of the temporary area.
4 De-allocates the old copy of Dest.
5 Allocates memory for Dest large enough to hold the result.
6 Copies the temporary data to Dest.
Steps 2 and 6 are very expensive and basically ...
MY NOTE: Microsoft admits that VB concat is tragedy.
>From previous exhibits it is obvious that Delphi can
do the job with by only doing modified step 3
(copy source to end of old dest area)
Exhibit F: From MSDN
This article details a method using the Mid$ statement and pre-allocating
memory in larger chunks to eliminate all but step 3 above for most
of the concatenation phase.
WARNING: ANY USE BY YOU OF THE CODE PROVIDED IN THIS ARTICLE IS
MY NOTE: to achieve performance in the same order of magnitude (but still
much slower) as Delphi,
Microsoft has nothing to offer Visual Basic developers other than hack.
We saw in exhibits A, B that Delphi that simple and logical syntax used in
Delphi
is both well documented and recommended by Borland.
In exhibits C and D we saw indications that it also works as advertised.
Conclusion, Delphi is nice and fast, VB is ugly and slow.
Exhibit F: From MSDN again
This article demonstrates the benefits of using the StringBuilder
class over traditional concatenation techniques. Strings in the .NET
Framework are invariant (that is, the referenced text is read-only after
the initial allocation). This provides many performance benefits and
poses some challenges to the developer who is accustomed to previous
versions of Visual Basic. One common Visual Basic 6.0 string concatenation
technique can be up to 1,000 times faster than the & operator, yet this
technique provides no performance benefits in Visual Basic .NET.
MY NOTE: This means VB.NET strings are different than
VB6 strings. They are equally slow (or slower), but you can't hack
against it as you could before.
Sad thing is that strings in NET by nature are not only VB.NET but
also C# and Delphi for NET strings.
Exhibit F: From Rudy Welthuis in 64bit thread
Eric, I already told you that everyone who simply assumes that
S := S + 'bla'; in a tight loop is optimal code, is making a huge mistake.
MY NOTE: Direct contradiction with all A, B, C and D
Exhibit G: From Delphi 8 FAQ
Can I reuse my existing Win32. Delphi applications?
Many Win32. VCL-based Delphi applications will port to .NET using the
Delphi 8 VCL controls for the .NET Framework.
Direct Win32 API calls and external x86 DLLs are
supported with minor source code changes.
MY NOTE: s1 := s1 + s2 is neither Win32 api nor x86 DLL.
So no minor source changes necessary.
So, app using clean and simple recommended technique
can choke in NET.
If you going to use StringBuilder, it cant pass as
minor change in anybody's book.
Conclusion: Borland statement in G directly contradicts
Borland statement A and B
- Next message: David Clegg: "Re: Database Independance"
- Previous message: David Clegg: "Re: Database Independance"
- Next in thread: K. Sallee: "Re: TeamB, Borland, admit obvious"
- Reply: K. Sallee: "Re: TeamB, Borland, admit obvious"
- Reply: John Herbster \(TeamB\): "Re: TeamB, Borland, admit obvious"
- Maybe reply: Nick Hodges (TeamB): "Re: TeamB, Borland, admit obvious"
- Reply: Rudy Velthuis (TeamB): "Re: TeamB, Borland, admit obvious"
- Maybe reply: Rudy Velthuis (TeamB): "Re: TeamB, Borland, admit obvious"
- Reply: Barry Kelly: "Re: TeamB, Borland, admit obvious"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|