Board index » delphi » Re: Myths of our time...

Re: Myths of our time...


2003-10-14 12:42:54 AM
delphi87
Sorry, but you still haven't *tried* and still think of a
"performance hog".
Blame the license forbidding publication of benchmark all you want,
but you will have to test yourself to know what it is about.
Quote
The fact that languages like Java and C# make strings immutable
has to do with managed and safe coding.
It hasn't *that much* to do with immutability. Try the thing.
Quote
On .NET you can not use Move() either. Get used to not thinkling of such
low level hacks.
Not even thinking about that. In fact, had you read my OP fully,
you could have noticed a reference to an even higher-level alternative,
even farther from low-level.
Besides, RTL's Move() would be quite inefficient in that particular case ;)
Quote
Using StringBuilder (or similar) for such code is evne something I would
recommend in Delphi.
Then I hope you recommanded it to Borland.
They have much VCL cleaning to do.
Quote
In .NET, it is readily available, and not much more
work than the simple concat loop you have.
If StringBuilder is that universal, why not aliasing string to StringBuilder?
Because StringBuilder isn't written in managed code?
Eric
 
 

Re: Myths of our time...

C4D - Kim Madsen writes:
Quote
The fact that it works with Delphi, is what most people need for real
life situations.
Perhaps, but that doesn't relieve one from knowing it is a coincidence,
and from not expecting this to work everywhere, or in the future.
Even if most code is written so "it works", a little more planning and
love for detail will make code a lot more maintainable. If it has become
a habit, it doesn't take any extra time.
--
Rudy Velthuis (TeamB)
"Man is the best computer we can put aboard a spacecraft... and the
only one that can be mass produced with unskilled labor."
-- Wernher von Braun
 

Re: Myths of our time...

C4D - Kim Madsen writes:
Quote
If we apply the same skills to writing code the traditional way, as you
want people to apply when writing code the dotNet way, Id be surprised
if the traditional way wouldnt perform better ;)
And I actually doubt it.
--
Rudy Velthuis (TeamB)
"I still live." - Daniel Webster, dying words
 

Re: Myths of our time...

But regardless of all the good wishful thinking about how it _should_ be with the human race, its most likely better to
look at how it infact is. Again that was the argument for GC, that humans were to stupid to release allocated ressources
:)
--
best regards
Kim Madsen
XXXX@XXXXX.COM
www.components4developers.com
The best components for the best developers
kbmMW - kbmMemTable - kbmWABD - kbmX10
"Rudy Velthuis (TeamB)" <XXXX@XXXXX.COM>skrev i en meddelelse news:XXXX@XXXXX.COM...
Quote
C4D - Kim Madsen writes:

>The fact that it works with Delphi, is what most people need for real
>life situations.

Perhaps, but that doesn't relieve one from knowing it is a coincidence,
and from not expecting this to work everywhere, or in the future.

Even if most code is written so "it works", a little more planning and
love for detail will make code a lot more maintainable. If it has become
a habit, it doesn't take any extra time.
--
Rudy Velthuis (TeamB)

"Man is the best computer we can put aboard a spacecraft... and the
only one that can be mass produced with unskilled labor."
-- Wernher von Braun
 

Re: Myths of our time...

The same the Java guys have been saying for years... and still, traditional compiled code is in general much faster.
There might be a reason why Windows Longhorn whatever, is not written in dotNet :)
--
best regards
Kim Madsen
XXXX@XXXXX.COM
www.components4developers.com
The best components for the best developers
kbmMW - kbmMemTable - kbmWABD - kbmX10
"Rudy Velthuis (TeamB)" <XXXX@XXXXX.COM>skrev i en meddelelse news:3f8ad6ba$XXXX@XXXXX.COM...
Quote
C4D - Kim Madsen writes:

>If we apply the same skills to writing code the traditional way, as you
>want people to apply when writing code the dotNet way, Id be surprised
>if the traditional way wouldnt perform better ;)

And I actually doubt it.
--
Rudy Velthuis (TeamB)

"I still live." - Daniel Webster, dying words
 

Re: Myths of our time...

Quote
Delphi seems to manage to keep it fast, without a lot of copying.
Actually, even with a lot of copying, it is still orders of magnitude
faster than what DotNet achieves... and won't eat memory like cops
eat donuts (read OP, try the things, notice and review how the DWS
version does that).
It's not the copying that kill the DotNet version.
Eric
PS: at least in movies, cops eat lots'o donuts ;)
 

Re: Myths of our time...

Eric Grange writes:
Quote
>Exactly. Not using StringBuilder in C# for such code is a big mistake.

If if give you a slightly altered example that will collapse with
StringBuilder too, will you eat your hat?
My hat is supplied by Borland, so I can't. <g>
I'd love to see an example. Of course it is possible to get every system
to its knees, but I am still curious.
--
Rudy Velthuis (TeamB)
"You can get more with a kind word and a gun than you can with a kind
word alone."
- Al Capone (1899-1947)
 

Re: Myths of our time...

ROFL. Good catch.
Eric
 

Re: Myths of our time...

Eric Grange writes:
Quote
Sorry, but you still haven't tried and still think of a
"performance hog".
*I* have tried it in Delphi.
Quote
Not even thinking about that. In fact, had you read my OP fully,
you could have noticed a reference to an even higher-level alternative,
even farther from low-level.
Besides, RTL's Move() would be quite inefficient in that particular
case ;)
Not really, if you wanted to add to the current end of a string in a huge
buffer. Either that, or the likes of StrCopy.
Quote
Then I hope you recommanded it to Borland.
They have much VCL cleaning to do.
They don't do it for large numbers of strings (except in a few newer
routines which have already been reported as being rather badly
designed). Of course it is OK for a few strings, there it won't make any
noticeable difference in performance.
Quote
If StringBuilder is that universal, why not aliasing string to
StringBuilder? Because StringBuilder isn't written in managed code?
Like Alisdair said: having two classes, optimized for their respective
jobs, makes sense. String is convenient and fast for simple work, string
builder for concatenations to form large strings.
--
Rudy Velthuis (TeamB)
"Attention to health is life's greatest hindrance."
- Plato (427-347 B.C.)
 

Re: Myths of our time...

Alessandro Federici writes:
Quote
"Rudy Velthuis (TeamB)" <XXXX@XXXXX.COM>writes
news:XXXX@XXXXX.COM...
>>I think the point made was clearly "this is wrong to do in .Net",
>>not in general.
>I think it is wrong to do in general, for large numbers.

I am not following Rudy
I meant it is not only wrong to do it in .NET, it is generally wrong, if
you want to build strings out of a large number of substrings. It is
nonsense to use a stringbuilder to concatenate two or three strings.
--
Rudy Velthuis (TeamB)
"Be nice to people on your way up because you meet them on your way down."
- Jimmy Durante
 

Re: Myths of our time...

Eric Grange writes:
Quote
>Delphi seems to manage to keep it fast, without a lot of copying.

Actually, even with a lot of copying, it is still orders of magnitude
faster than what DotNet achieves...
Give me an example *with* a lot of copying.
--
Rudy Velthuis (TeamB)
"Smith & Wesson ?the original point and click interface."
 

Re: Myths of our time...

C4D - Kim Madsen writes:
Quote
But regardless of all the good wishful thinking about how it should be
with the human race, its most likely better to look at how it infact
is. Again that was the argument for GC, that humans were to stupid to
release allocated ressources :)
They are not necessarily too stupid. They can simply forget. Compilers
and runtimes, once taught how to do it, are much better at not forgetting
such things.
--
Rudy Velthuis (TeamB)
"Common sense is the collection of prejudices acquired by age eigh{*word*249}."
-- Albert Einstein
 

Re: Myths of our time...

Quote
Perhaps because YOU repeatedly claimed that this example proved that
the String class was not safe to return from fns, that ALL string
concatenation was expensive, and so on and on and on and on.
Did you actually try anything? No? Please do.
Quote
(Cartoonishly, a web server that might allocate a few K of temp
variables and then be all done with them as soon as it finishes the
request.)
You mean DotNet is barely a stripped-down Python clone capacity-wise?
I don't want my Delphi apps to run from that ;)
Quote
There are pathological cases where you can make gc really
really slow. (Try using most of the physical memory.) So?
100000 allocations is far far far from being a stress situation,
and 800k is far far far from being a huge chunk of memory nowadays.
Quote
In most cases, "the Garbage Collector being beneficial at a borderline
performance-cost" is no myth.
I yet have to find any case, just one, don't need more, where it is more
efficient (in terms of memory use AND speed) than a recycling memory
manager (uses a clustered heap, the Delphi MM uses a basic heap, which reduces
memory consumption at the cost of performance and fragmentation. Recycling MM
consume more memory, though typically only a fraction of what a GC needs to
operate smoothly).
If you got a case, just one, please, submit it.
Eric
 

Re: Myths of our time...

C4D - Kim Madsen writes:
Quote
The same the Java guys have been saying for years... and still,
traditional compiled code is in general much faster.
Do you have access to the German magazine c't? It shows that this is
actually not true. C++ code (both MS and Borland) showed to be slower
(for code that was a little more complicated than a few simple loops)
than Java.
--
Rudy Velthuis (TeamB)
"Smith & Wesson ?the original point and click interface."
 

Re: Myths of our time...

I have seen those 'proofs'
And so have there been proofs in real world apps of the opposite.
Fabricated benchmarks are really not showing anything but what the benchmarkers want to show.
--
best regards
Kim Madsen
XXXX@XXXXX.COM
www.components4developers.com
The best components for the best developers
kbmMW - kbmMemTable - kbmWABD - kbmX10
"Rudy Velthuis (TeamB)" <XXXX@XXXXX.COM>skrev i en meddelelse news:3f8adcc5$XXXX@XXXXX.COM...
Quote
C4D - Kim Madsen writes:

>The same the Java guys have been saying for years... and still,
>traditional compiled code is in general much faster.

Do you have access to the German magazine c't? It shows that this is
actually not true. C++ code (both MS and Borland) showed to be slower
(for code that was a little more complicated than a few simple loops)
than Java.
--
Rudy Velthuis (TeamB)

"Smith & Wesson - the original point and click interface."