Discussion:
Three strikes...
(too old to reply)
Lauchlan M
2006-02-27 01:27:57 UTC
Permalink
We believed the hype that Delphi 2006 had been done right, and got
upgrades
for all our D7 licences. Incredibly slow compile times and very
unstable...
Strike Three.
(i) What are your system specs (D2006 requires *at least* 512MB RAM, you
probably should have at least 1GB to be happy; do you have lots of free disk
space, do you have a fast processor).

(ii) did you apply the update?

Lauchlan M
Jolyon Smith
2006-02-27 01:43:29 UTC
Permalink
We're starting a serious evaluation of Visual Studio, with a view to
rewriting in C++.
Out of curiosity, why not C#?

Surely the migration from OP to C# should be much more straight forward
than OP to C++
--
Jolyon Smith
Alistair Ward
2006-02-27 03:29:06 UTC
Permalink
Post by Jolyon Smith
We're starting a serious evaluation of Visual Studio, with a view to
rewriting in C++.
Out of curiosity, why not C#?
Surely the migration from OP to C# should be much more straight forward
than OP to C++
Mostly because of our bad experience with Delphi 8 and .Net.

We managed to port most of our app to .Net (despite Delphi 8!), but the end
result was an absolute dog - used 3 times the memory and ran at half the
speed of our native Win32 app.

Now, I will be the first to admit that we did *not* make much of an attempt
to optimise for .Net, given that D8 was so awful, but we felt a reasonable
amount of our problems were the .Net platform, rather than just D8.
Post by Jolyon Smith
--
Jolyon Smith
Alistair.
Jon Shemitz
2006-02-27 04:56:31 UTC
Permalink
Post by Alistair Ward
Now, I will be the first to admit that we did *not* make much of an attempt
to optimise for .Net, given that D8 was so awful, but we felt a reasonable
amount of our problems were the .Net platform, rather than just D8.
Naah. Going to C# (& VS.2002) from D7 felt to me like the productivity
jump I got going to D1 from BPW.
--
<http://www.midnightbeach.com>
Joanna Carter [TeamB]
2006-02-27 07:35:39 UTC
Permalink
"Alistair Ward" <***@forum8.co.nz> a écrit dans le message de news:
***@newsgroups.borland.com...

| Mostly because of our bad experience with Delphi 8 and .Net.
|
| We managed to port most of our app to .Net (despite Delphi 8!), but the
end
| result was an absolute dog - used 3 times the memory and ran at half the
| speed of our native Win32 app.
|
| Now, I will be the first to admit that we did *not* make much of an
attempt
| to optimise for .Net, given that D8 was so awful, but we felt a reasonable
| amount of our problems were the .Net platform, rather than just D8.

Delphi 8 was the first .NET Delphi compiler, the IDE and compiler were
released way too early. .NET 1.1 apps typically run slower than Win32 apps,
.NET 2.0 apps are noticably faster but, if you want to move to .NET, then
you have to decide whether you want to stay with the Delphi language or
switch to any other language. BDS 2005 also allows you to write in C#, but
the resulting code is no different from Delphi code as it is all compiled to
the same IL code.

If your Delphi code included things like multiple concatenations of strings,
then this is a well known bottleneck; strings are immutable in .NET and a
new string is allocated every time you modify a string. The recommended way
of building long strings in .NET is to use the StringBuilder class. This and
other differences in programming for .NET can certainly influence the speed
of your apps if you simply try to recompile a Win32 app to .NET.

Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
Eric Grange
2006-02-27 07:48:39 UTC
Permalink
BDS 2005 also allows you to write in C#, but the resulting code is no
different from Delphi code as it is all compiled to the same IL code.
Actually, that's incorrect. It doesn't compile to the same IL instructions, and
there are many occurences, from loops to floating point, where a marked
runtime performance difference can be observed on similar-looking source code
(including times when the C# aims squarely for a JITter peephole optimization
that the D.Net compiler doesn't know or doesn't care about, and many of the
JITter optimizations being peephole-based...).

That all compilers did compile to x86 didn't mean they achieved the same
results, and that is the case in the IL world too.

Eric
Atmapuri
2006-02-27 09:39:24 UTC
Permalink
Hi!
Post by Eric Grange
Actually, that's incorrect. It doesn't compile to the same IL
instructions, and there are many occurences, from loops to floating point,
where a marked runtime performance difference can be observed on
similar-looking source code (including times when the C# aims squarely for
a JITter peephole optimization that the D.Net compiler doesn't know or
doesn't care about, and many of the JITter optimizations being
peephole-based...).
Very true. However, who in his right mind would want to write performance
sensitive code in .NET, without direct access to unmanaged code (libraries
or mixed code)?

About .NET 2.0. You can still compile your assemblies against .NET v1.1
and when it is called from .NET 2.0 app, the entire assembly is JIT-ed with
the v2.0 codegen.

Regards!
Atmapuri
Lord Crc
2006-02-27 18:52:48 UTC
Permalink
On Mon, 27 Feb 2006 10:39:24 +0100, "Atmapuri"
Post by Atmapuri
Very true. However, who in his right mind would want to write performance
sensitive code in .NET, without direct access to unmanaged code (libraries
or mixed code)?
Most things I've written in .NET aren't THAT much slower (typically
less than 2x), and some are actually faster. I use only "safe" managed
code. For many applications, I can imagine this is quite acceptable if
other features of the .NET framework makes development easier.

It did however take some time to get used to the differences and know
what's the performance killers (still not finished in that department
though :)

- Asbjørn
Mike Swaim
2006-02-27 18:53:46 UTC
Permalink
Post by Atmapuri
Very true. However, who in his right mind would want to write
performance sensitive code in .NET, without direct access to
unmanaged code (libraries or mixed code)?
Depending on where you do this, it could be a bad idea. There is a
performance cost going managed <-> unmanaged, and this can easily be
more than the savings of an unmanaged implementation vs. a managed
implementation.
--
Mike Swaim ***@hal-pc.org at home | Quote: "Boingie"^4 Y,W & D
MD Anderson Dept. of Biostatistics & Applied Mathematics
***@mdanderson.org or ***@odin.mdacc.tmc.edu at work
ICBM: 29.763N 95.363W|Disclaimer: Yeah, like I speak for MD Anderson.
Atmapuri
2006-02-28 06:54:35 UTC
Permalink
Hi!~
Post by Mike Swaim
Depending on where you do this, it could be a bad idea. There is a
performance cost going managed <-> unmanaged, and this can easily be
more than the savings of an unmanaged implementation vs. a managed
implementation.
Of course. Unless it is done properly.

Best Regards!
Atmapuri
Alistair Ward
2006-02-27 01:46:24 UTC
Permalink
Post by Lauchlan M
We believed the hype that Delphi 2006 had been done right, and got
upgrades
for all our D7 licences. Incredibly slow compile times and very
unstable...
Strike Three.
(i) What are your system specs (D2006 requires *at least* 512MB RAM, you
probably should have at least 1GB to be happy; do you have lots of free disk
space, do you have a fast processor).
Dual Opteron 275, with 4GB RAM (XP 64bit edition).
Post by Lauchlan M
(ii) did you apply the update?
Haven't applied update 1, although my understanding was that it was only for
C++ Builder (which we don't use).

Alistair.
Lauchlan M
2006-02-27 02:04:43 UTC
Permalink
Post by Alistair Ward
Post by Lauchlan M
(ii) did you apply the update?
Haven't applied update 1, although my understanding was that it was only for
C++ Builder (which we don't use).
No, it's a general update fixing various bugs (for Delphi, C#, IDE, etc).

I suggest you try that then . . .

HTH

Lauchlan M
Jolyon Smith
2006-02-27 02:12:18 UTC
Permalink
In article <***@newsgroups.borland.com>, "Lauchlan M"
<LMackinnonAT_NoSpam_ozemailDOTcomDOTau> says...
Post by Lauchlan M
Post by Alistair Ward
Post by Lauchlan M
(ii) did you apply the update?
Haven't applied update 1, although my understanding was that it was only
for
Post by Alistair Ward
C++ Builder (which we don't use).
No, it's a general update fixing various bugs (for Delphi, C#, IDE, etc).
Really?

How come I (and others) got lambasted for naively suggesting that
perhaps the timing of Update #1 was indicative that D2006 was a bit
rushed?

We all got shot down for not having clairvoyance sufficient to know that
Update #1 was just the C++ personality that had already been identified
as to be shipped in an early update.

(Clairvoyance because we a] weren't BDS2006 users - yet - and b] weren't
C++ users, so had no real reason to know and only had an announcement of
an update to go on at the time)

Are we saying now that it was more thanjust the C++ update?
--
Jolyon Smith
Lauchlan M
2006-02-27 02:20:12 UTC
Permalink
Post by Jolyon Smith
Post by Lauchlan M
No, it's a general update fixing various bugs (for Delphi, C#, IDE, etc).
Really?
Well, I thought it was.

I thought there was a list of bugs fixed that came with it, and some of them
sounded like they were more general than C++. But maybe it just wasn't made
very clear, and they were all really C++ related.

Lauchlan M
Jon Robertson
2006-02-27 03:03:56 UTC
Permalink
Post by Lauchlan M
No, it's a general update fixing various bugs (for Delphi, C#, IDE, etc).
No. It was specifically to bring the "C++ Preview" to a
full-production version of C++. This was clear in the Open Letter,
which is still on BDN:
http://bdn.borland.com/article/0,1410,33404,00.html

Now, there were some things fixed in the IDE, because they impacted
C++. Some of those also impacted Delphi users. However, no specific
Delphi or C# bugs were fixed, to the best of my knowledge.
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
http://www.medevolve.com
Jon Robertson
2006-02-27 03:05:55 UTC
Permalink
Post by Alistair Ward
Dual Opteron 275, with 4GB RAM (XP 64bit edition)
Does anyone else have any experience using BDS 2006 with XP 64bit? I
haven't heard of any. Since this variable is different from most BDS
2006 users, I'd be curious.
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
http://www.medevolve.com
Vincent Parrett (VSoft Technologies)
2006-02-27 04:23:06 UTC
Permalink
Post by Jon Robertson
Post by Alistair Ward
Dual Opteron 275, with 4GB RAM (XP 64bit edition)
Does anyone else have any experience using BDS 2006 with XP 64bit? I
haven't heard of any. Since this variable is different from most BDS
2006 users, I'd be curious.
I've been using D2006 on a Dual Core AMD box running XP 64bit for just over
a week. So far so good.

I've had more problems with other software than with delphi, finally found a
printer driver but it just ignores the print settings (very painfull)! Some
programs I use wouldn't install on the machine at all (installer refused) so
at this time I'm seriously considering switching back to 32bit XP.
--
--
Regards

Vincent Parrett
VSoft Technologies
http://www.finalbuilder.com
Blogs : http://blogs.finalbuilder.com
----------------------------------------
Automate your Build Process with FinalBuilder
Daniel Smith
2006-02-27 01:01:25 UTC
Permalink
We believed the hype that Delphi 2006 had been done right, and got upgrades
for all our D7 licences. Incredibly slow compile times and very unstable...
Strike Three.
Strike one:

Lack of detail in your post. On what projects does it compile slowly? All of them? Perhaps give a test case. How is it "unstable"?

Strike two:

No mention of a QC report

Strike three:

You've apparently given up without having pursued the actions outlined in strikes one and two.

Given the above, folks might be forgiven for thinking your post is nothing but a troll. OK, so I took the bait.
--
Dan
Alistair Ward
2006-02-27 03:21:35 UTC
Permalink
Post by Daniel Smith
We believed the hype that Delphi 2006 had been done right, and got upgrades
for all our D7 licences. Incredibly slow compile times and very unstable...
Strike Three.
Lack of detail in your post. On what projects does it compile slowly? All
of them? Perhaps give a test case. How is it "unstable"?
Since you asked...

It is slow compiling the exe's. The BPL's all compile reasonably quickly
(but still noticeably slower than D7). The exe's (as stated earlier) are
about 9MB of source spread over about 300 source files.

When we timed things earlier today, the "Build" time wasn't much slower than
D7 (2m30s for D2006 vs 2m10s for D7) . The killer was the "Compile" time. In
the process of updating the source to D2006, a "Compile" took up to 7
minutes before it stopped and reported errors.


Instability. Start D2006 (Win32 personality only), load project. Change 1
line (add a space!) and compile/run. Quit program. Change line back again,
and compile/run. D2006 dies (goes away...). Always need Task Manager
running, because it is need to kill D2006 on a regular basis. Need to
restart D2006 regularly.

We're not running any add-ons, and have very few additional components.
Post by Daniel Smith
No mention of a QC report
True... We did have direct communicatons with Borland about compiler speed
when we looked at D2005, but didn't get any resolution.

If we could get something consistently reproducable re instabilities, we
would put something into QC.
Post by Daniel Smith
You've apparently given up without having pursued the actions outlined in
strikes one and two.
Now, now... this is hardly a 3rd strike :-)
Post by Daniel Smith
Given the above, folks might be forgiven for thinking your post is nothing
but a troll. OK, so I took the bait.
Not intended as a troll... more a howl of frustration.

We hate the thought of changing to C++ - the costs involved are just so
horrific given the huge existing code base that we have, and the fact that
we really *don't* like C++. We *want* to stay using Delphi, but we have been
frustrated by the quality of the last 3 releases of Delphi. I don't expect
anything useful to come out of posting here, beyond venting a little bit of
steam.
Post by Daniel Smith
--
Dan
Alistair.
Lauchlan M
2006-02-27 03:32:24 UTC
Permalink
Post by Alistair Ward
We're not running any add-ons, and have very few additional components.
Which components do you have?

Do you have the same problems if you uninstall the components (/ did you
have the same problem before you installed the components)?

One or more of your components may be behind the problem, in which case
maybe it's not entirely fair to blame it all on Delphi . . .

HTH

Lauchlan M
Lauchlan M
2006-02-27 03:34:28 UTC
Permalink
Post by Alistair Ward
We hate the thought of changing to C++ - the costs involved are just so
horrific given the huge existing code base that we have, and the fact that
we really *don't* like C++. We *want* to stay using Delphi, but we have been
frustrated by the quality of the last 3 releases of Delphi. I
Then why couldn't you stick with D7 until Borland (if they do) release a
version that in your experience is better?

Surely that's easier than prting to C++ . . .

Lauchlan M
Alistair Ward
2006-02-27 03:49:08 UTC
Permalink
Post by Lauchlan M
Post by Alistair Ward
We hate the thought of changing to C++ - the costs involved are just so
horrific given the huge existing code base that we have, and the fact that
we really *don't* like C++. We *want* to stay using Delphi, but we have
been
Post by Alistair Ward
frustrated by the quality of the last 3 releases of Delphi. I
Then why couldn't you stick with D7 until Borland (if they do) release a
version that in your experience is better?
Surely that's easier than prting to C++ . . .
Lauchlan M
We probably will stick with Delphi 7.

It's just that we're about to do some major redesign of our application, and
if we're going to change, then now is probably the best time to do it
(there's never a good time, but this is probably the least bad time!).

Alistair.
Mark A. Andrews
2006-02-27 03:54:31 UTC
Permalink
Post by Lauchlan M
Then why couldn't you stick with D7 until Borland (if they do) release a
version that in your experience is better?
Surely that's easier than prting to C++ . . .
I agree. As bad as D2005 was and since I don't see any real reason to
switch to D2006 for Win32 development, I'm sticking with Delphi 7.0 (for
the time being). Delphi 7.0 is still better than any other non-Borland
environment for creating Win32 Apps.

Mark
David Farrell-Garcia
2006-02-27 14:49:04 UTC
Permalink
Post by Lauchlan M
Then why couldn't you stick with D7 until Borland (if they do)
release a version that in your experience is better?
Good question and that is exaclty why I give ZERO credibility to these
kinds of posts. No person, in their right mind, who was previously
satisfied with D7, would move to VS/C++ because they don't like D2006,
rather then simply move back to D7. That is just ridiculous.
--
Ingvar Nilsen
2006-02-27 16:05:02 UTC
Permalink
Post by David Farrell-Garcia
Post by Lauchlan M
Then why couldn't you stick with D7 until Borland (if they do)
release a version that in your experience is better?
Good question and that is exaclty why I give ZERO credibility to these
kinds of posts. No person, in their right mind, who was previously
satisfied with D7, would move to VS/C++ because they don't like D2006,
rather then simply move back to D7. That is just ridiculous.
Is D7 still available?
What if the team is extended, you need more D7 licenses?
--
Ingvar Nilsen
http://www.ingvarius.com
Charles McAllister
2006-02-27 16:17:30 UTC
Permalink
Post by Ingvar Nilsen
Is D7 still available?
What if the team is extended, you need more D7 licenses?
give the new guy D2006. he won't know the difference <g>.
David Farrell-Garcia
2006-02-28 01:33:02 UTC
Permalink
Post by Ingvar Nilsen
Is D7 still available?
What if the team is extended, you need more D7 licenses?
I am sure it would be eaiser to obtain additional D7 licenses then it
would be to move to VS.Net/C++
Alistair Ward
2006-02-27 21:01:54 UTC
Permalink
Post by David Farrell-Garcia
Post by Lauchlan M
Then why couldn't you stick with D7 until Borland (if they do)
release a version that in your experience is better?
Good question and that is exaclty why I give ZERO credibility to these
kinds of posts. No person, in their right mind, who was previously
satisfied with D7, would move to VS/C++ because they don't like D2006,
rather then simply move back to D7. That is just ridiculous.
--
As I said in reply to someone else, we probably will stick with D7 - the
costs of rewriting a large code base are really too large.

The problem is that while D7/Win32 is adequate for now, it won't always be
(we figure another year or 2 at most before we have to move forward to newer
platforms). We are at a point of doing some major redesign of our app, so if
we were going to make a change, then now would probably be the least bad
time to do it (there is *no* good time :-( )

Alistair.
J. Lee
2006-02-27 21:23:30 UTC
Permalink
Our shop went through this thinking game back when M$ made it appear
that Win32 was dead and you must use .NET. We concluded that Win32 will
be around for at least another 10 years. As long as Win32 is around,
we're sticking with Delphi. In another 5 years, we'll re-assess.

The next re-design of our app will take advantage of some of Vista's
graphical abilities--we are really really hoping there will be Win32 API
interfaces to the new graphics system (Avalon?).

~J. Lee
Post by Alistair Ward
As I said in reply to someone else, we probably will stick with D7 - the
costs of rewriting a large code base are really too large.
The problem is that while D7/Win32 is adequate for now, it won't always be
(we figure another year or 2 at most before we have to move forward to newer
platforms). We are at a point of doing some major redesign of our app, so if
we were going to make a change, then now would probably be the least bad
time to do it (there is *no* good time :-( )
Alistair.
Lauchlan M
2006-02-28 06:23:42 UTC
Permalink
Post by Alistair Ward
platforms). We are at a point of doing some major redesign of our app, so if
we were going to make a change, then now would probably be the least bad
time to do it (there is *no* good time :-( )
If you are doing a lot of redesigning, perhaps the Delphi 2006 refactorings
will end up being really useful to you.

Lauchlan M
Xavier
2006-02-27 07:49:44 UTC
Permalink
Post by Alistair Ward
Instability. Start D2006 (Win32 personality only), load project. Change 1
line (add a space!) and compile/run. Quit program. Change line back again,
and compile/run. D2006 dies (goes away...). Always need Task Manager
running, because it is need to kill D2006 on a regular basis. Need to
restart D2006 regularly.
My first go at it was similar, lots of freezing, access violations, ...
particularly when using code insight features, the IDE would go
belly-up on short notice. It all stopped after removing all old DCUs
from the library paths. I have no idea why it didn't just regenerate
them from source, but that fixed it for me. It's been almost rock-solid
since.
Henrick Hellström [StreamSec]
2006-02-27 12:24:12 UTC
Permalink
Post by Alistair Ward
When we timed things earlier today, the "Build" time wasn't much slower than
D7 (2m30s for D2006 vs 2m10s for D7) . The killer was the "Compile" time. In
the process of updating the source to D2006, a "Compile" took up to 7
minutes before it stopped and reported errors.
Did you clear the path of any D7 dcu files? I would expect to see a
similar result when doing a Compile if there are dcu files generated by
an old version of the compiler in the path. Not just when updating to
D2006 specifically, but when updating from any old version of Delphi to
any newer version.
Ingvar Anderberg
2006-02-28 19:56:30 UTC
Permalink
Did you clear the path of any D7 dcu files? I would expect to see a similar result when doing a Compile if there are dcu files
generated by an old version of the compiler in the path. Not just when updating to D2006 specifically, but when updating from any
old version of Delphi to any newer version.
Exactly,
I thought I have, until I completely uninstalled
the previous version of Delphi, when BDS 2006 begin to
complain about missing files belonging the older version.

/ia
Ingvar Nilsen
2006-02-27 13:23:42 UTC
Permalink
Post by Alistair Ward
It is slow compiling the exe's. The BPL's all compile reasonably
quickly (but still noticeably slower than D7). The exe's (as stated
earlier) are about 9MB of source spread over about 300 source files.
While a full build probably has to be undertaken on a regular basis,
isn't it possible with such a large project to divide it into separate
entities? Not knowing your applications, it would be sensible to assume
that.
--
Ingvar Nilsen
http://www.ingvarius.com
David Farrell-Garcia
2006-02-27 14:45:19 UTC
Permalink
Post by Alistair Ward
Since you asked...
Sounds to me like you have a system that is not up to the task of
running D2006. I have no such problems. The IDE is noticibly slower
then D7 but I expected that given all the new IDE stuff. If you have
been reading the posts you will see that your issues are not what most
people are experiencing so rather then blame D2006 why not look at your
own system? Have you tried this on a different machine?
Arthur Hoornweg
2006-02-27 15:41:37 UTC
Permalink
Post by Alistair Ward
When we timed things earlier today, the "Build" time wasn't much slower than
D7 (2m30s for D2006 vs 2m10s for D7) . The killer was the "Compile" time. In
the process of updating the source to D2006, a "Compile" took up to 7
minutes before it stopped and reported errors.
Check the search- and library paths in the IDE. It greatly affects speed
to specify
the paths in the correct order.
--
Arthur Hoornweg

(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)
Randy Magruder
2006-02-27 15:52:14 UTC
Permalink
Post by Alistair Ward
Not intended as a troll... more a howl of frustration.
We hate the thought of changing to C++ - the costs involved are just
so horrific given the huge existing code base that we have, and the
fact that we really don't like C++. We want to stay using Delphi, but
we have been frustrated by the quality of the last 3 releases of
Delphi. I don't expect anything useful to come out of posting here,
beyond venting a little bit of steam.
I just don't get it. I use BDS2006 every day, for way more than the 8
hours of a work day (I have projects on the side that i use) . There
are what I would call 'pockets of instability' here and there doing
certain kinds of things, but for my Delphi win32 development, it's been
very solid for me. I can easily go all day without a crash or a
restart of BDS2006 needed.

May I ask what kind of system you're running it on? Memory, etc?

Randy
Adam Markowitz (Borland)
2006-02-27 18:13:57 UTC
Permalink
Alistair,
Is there a possibility of getting test cases for the slow compile problem
and the IDE disappearing problem? It would be much appreciated.

Thanks!,
-Adam
Post by Alistair Ward
Post by Daniel Smith
We believed the hype that Delphi 2006 had been done right, and got upgrades
for all our D7 licences. Incredibly slow compile times and very unstable...
Strike Three.
Lack of detail in your post. On what projects does it compile slowly? All
of them? Perhaps give a test case. How is it "unstable"?
Since you asked...
It is slow compiling the exe's. The BPL's all compile reasonably quickly
(but still noticeably slower than D7). The exe's (as stated earlier) are
about 9MB of source spread over about 300 source files.
When we timed things earlier today, the "Build" time wasn't much slower
than D7 (2m30s for D2006 vs 2m10s for D7) . The killer was the "Compile"
time. In the process of updating the source to D2006, a "Compile" took up
to 7 minutes before it stopped and reported errors.
Instability. Start D2006 (Win32 personality only), load project. Change 1
line (add a space!) and compile/run. Quit program. Change line back again,
and compile/run. D2006 dies (goes away...). Always need Task Manager
running, because it is need to kill D2006 on a regular basis. Need to
restart D2006 regularly.
We're not running any add-ons, and have very few additional components.
Post by Daniel Smith
No mention of a QC report
True... We did have direct communicatons with Borland about compiler speed
when we looked at D2005, but didn't get any resolution.
If we could get something consistently reproducable re instabilities, we
would put something into QC.
Post by Daniel Smith
You've apparently given up without having pursued the actions outlined in
strikes one and two.
Now, now... this is hardly a 3rd strike :-)
Post by Daniel Smith
Given the above, folks might be forgiven for thinking your post is
nothing but a troll. OK, so I took the bait.
Not intended as a troll... more a howl of frustration.
We hate the thought of changing to C++ - the costs involved are just so
horrific given the huge existing code base that we have, and the fact that
we really *don't* like C++. We *want* to stay using Delphi, but we have
been frustrated by the quality of the last 3 releases of Delphi. I don't
expect anything useful to come out of posting here, beyond venting a
little bit of steam.
Post by Daniel Smith
--
Dan
Alistair.
Alistair Ward
2006-02-27 21:07:00 UTC
Permalink
Post by Adam Markowitz (Borland)
Alistair,
Is there a possibility of getting test cases for the slow compile problem
and the IDE disappearing problem? It would be much appreciated.
Thanks!,
-Adam
I'm not sure what is happening with the IDE disappearing, I'll keep looking
a bit longer to see what is happening.

Re the slow compile times, I will email you offline with copies of
correspondence we had (indirectly) with Danny last year.

Thanks,
Alistair.
Adam Markowitz (Borland)
2006-02-27 21:18:18 UTC
Permalink
Alistair,
Sounds good.

Thanks,
-Adam
Post by Alistair Ward
Post by Adam Markowitz (Borland)
Alistair,
Is there a possibility of getting test cases for the slow compile
problem and the IDE disappearing problem? It would be much appreciated.
Thanks!,
-Adam
I'm not sure what is happening with the IDE disappearing, I'll keep
looking a bit longer to see what is happening.
Re the slow compile times, I will email you offline with copies of
correspondence we had (indirectly) with Danny last year.
Thanks,
Alistair.
Brad White
2006-02-28 00:36:38 UTC
Permalink
Post by Alistair Ward
Post by Daniel Smith
We believed the hype that Delphi 2006 had been done right, and got upgrades
for all our D7 licences. Incredibly slow compile times and very unstable...
Strike Three.
Lack of detail in your post. On what projects does it compile slowly? All
of them? Perhaps give a test case. How is it "unstable"?
Since you asked...
It is slow compiling the exe's. The BPL's all compile reasonably quickly
(but still noticeably slower than D7). The exe's (as stated earlier) are
about 9MB of source spread over about 300 source files.
I'd try using FileMon from Sysinternals.com to try to find
directories that it is looking at that it shouldn't be wasting time on
or files it is trying to find that it can't, etc.
--
HTH,
Brad.
Charles McAllister
2006-02-27 01:58:53 UTC
Permalink
We believed the hype that Delphi 2006 had been done right, and got upgrades
for all our D7 licences. Incredibly slow compile times and very unstable...
Strike Three.
I wouldn't call it "incredibly slow" but from what i experienced from the trial edition, i'd say D2006 (trial) compiles about twice as slow as D7. But since D7 compiles "incredibly fast", i'd say D2006 compiles quickly.

the issue of compile time isn't a problem for me, since i could start building with runtime packages. the reason why i'm not going to upgrade is because i've got a third-party library that's not playing well with D2006 (and i don't blame borland for this at all).
Charles McAllister
2006-02-27 02:03:31 UTC
Permalink
Post by Charles McAllister
I wouldn't call it "incredibly slow" but from what i experienced from
the trial edition, i'd say D2006 (trial) compiles about twice as slow as
D7. But since D7 compiles "incredibly fast", i'd say D2006 compiles
quickly.
i should add that 'your mileage may vary' and may very well be some issue with my particular system. in other words, this is just one guy's opinion, who played with the trial for a day.

just curious, would there be a reason why the trial edition would compile slower than the purchased edition?
John Herbster
2006-02-27 12:59:12 UTC
Permalink
... I should add that 'your mileage may vary' ...
I sure hope that Borland is researching programmers'
driving habits and environments, in order to produce
more efficient tools. --JohnH
Charles McAllister
2006-02-27 14:19:30 UTC
Permalink
Post by John Herbster
I sure hope that Borland is researching programmers'
driving habits and environments, in order to produce
more efficient tools. --JohnH
well at least their environments :)
Crazy Horse's crazier little brother
2006-02-27 15:04:16 UTC
Permalink
Post by Charles McAllister
Post by John Herbster
I sure hope that Borland is researching programmers'
driving habits and environments, in order to produce more efficient
tools. --JohnH
well at least their environments :)
Yeah, I think Charles broke two cars in the four months that I knew him. <g>

Well, one was broke for him by someone else...
--
Download the latest draft (version 1.27, updated 2/2/2006) of
"STILL CASTING SHADOWS: A Shared Mosaic of U.S. History"
by Blackbird Crow Raven: http://cc.borland.com/ccweb.exe/listing?id=23106
Charles McAllister
2006-02-27 15:36:05 UTC
Permalink
Post by Crazy Horse's crazier little brother
Yeah, I think Charles broke two cars in the four months that I knew him. <g>
LOL. that's because i'm too cheap to buy a real car :)
...but we're getting off topic.
JED
2006-02-27 02:08:27 UTC
Permalink
Post by Charles McAllister
We believed the hype that Delphi 2006 had been done right, and got
upgrades for all our D7 licences. Incredibly slow compile times
and very unstable... Strike Three.
I wouldn't call it "incredibly slow" but from what i experienced from
the trial edition, i'd say D2006 (trial) compiles about twice as slow
as D7.
I guess you can't add language enhancements without it costing
something.
--
http://www.jed-software.com
http://jedqc.blogspot.com
Charles McAllister
2006-02-27 22:04:15 UTC
Permalink
Post by Charles McAllister
I wouldn't call it "incredibly slow" but from what i experienced from
the trial edition, i'd say D2006 (trial) compiles about twice as slow as
D7.
Issue solved. see Steve Trefethen's post below
Joseph Mele
2006-02-27 01:22:16 UTC
Permalink
Not just that but why would anyone upgrade all your licences without buying
on copy of D2006 and testing the migration???


And btw D2006 was done right

Joe Mele
www.youseful.com
www.fmplugin.net
Post by Lauchlan M
We believed the hype that Delphi 2006 had been done right, and got
upgrades
for all our D7 licences. Incredibly slow compile times and very
unstable...
Strike Three.
(i) What are your system specs (D2006 requires *at least* 512MB RAM, you
probably should have at least 1GB to be happy; do you have lots of free disk
space, do you have a fast processor).
(ii) did you apply the update?
Lauchlan M
Alistair Ward
2006-02-27 03:40:20 UTC
Permalink
Post by Joseph Mele
Not just that but why would anyone upgrade all your licences without
buying on copy of D2006 and testing the migration???
Yep... we went through that with both D8 and D2005, and ended up not
changing. We thought they might have actually got it right this time.

All the previous upgrades of Delphi 2 ->3 -> 4 -> 5 -> 6 -> 7 all went
without problems :-)
Post by Joseph Mele
And btw D2006 was done right
Done right for you. Maybe done right for most people. Not for us.

YMMV.
Post by Joseph Mele
Joe Mele
www.youseful.com
www.fmplugin.net
Alistair.
JED
2006-02-27 02:57:08 UTC
Permalink
We're starting a serious evaluation of Visual Studio, with a view to
rewriting in C++.
So the compiler performance isn't a big deal then?
--
http://www.jed-software.com
http://jedqc.blogspot.com
Alistair Ward
2006-02-27 04:36:56 UTC
Permalink
Post by JED
We're starting a serious evaluation of Visual Studio, with a view to
rewriting in C++.
So the compiler performance isn't a big deal then?
Yeah, I thought that was funny, too.
"We don't like your build times so we're evaluating something with
notoriously slow build times. Take that!" It's almost Monty
Pythonesque :)
I know :-(

The issues we have are both compiler speed and stability. Ultimately the
stability is the major issue.

We can live with slow compile times if the tool is ok in other respects, but
we don't really care if the compiler is blazing fast if the IDE won't hang
together for more than 1/2 an hour.
--
Regards,
Bruce McGee
Glooscap Software
Alistair Ward.
JED
2006-02-27 03:40:30 UTC
Permalink
Post by Alistair Ward
We can live with slow compile times if the tool is ok in other
respects, but we don't really care if the compiler is blazing fast if
the IDE won't hang together for more than 1/2 an hour.
What are your stability issues? Your OP doesn't appear to mention them.

Hopefully your VS evaluation includes a solution with 40 projects and
the same amount of source.
--
http://www.jed-software.com
http://jedqc.blogspot.com
Moni
2006-02-27 07:24:04 UTC
Permalink
What's wrong with just sticking with D7?

That's what we're doing until we can fully migrate to C#.

M
Atmapuri
2006-02-27 09:34:25 UTC
Permalink
Hi!
Post by Alistair Ward
We can live with slow compile times if the tool is ok in other respects,
but we don't really care if the compiler is blazing fast if the IDE won't
hang together for more than 1/2 an hour.
You have to be carefull to disable error insight. That greatly
affects stability. About IDE itself. I can only say, that the debugger is
still having trouble and is in fact less stable than D7.

It also makes sense, if you think about it. The customers first
report bugs with the code editor, then they report bugs with the
compiler and finally they report bugs with the debugger...

Delphi 8 was at code editor level.
D2005 came to the compiler problems.
D2006 is now at the debugger point.

And most finally customers report bugs with the performance of
the resulting exe.

Your rendering application however should be executing
substantially faster as when compiled with D7, unless you
did a lot of stuff in asm.

If you did not know: VS.NET is substantially less stable
than the VS6 (last unmanaged code version).

Best Regards!
Atmapuri
Arthur Hoornweg
2006-02-27 15:39:43 UTC
Permalink
Post by Atmapuri
You have to be carefull to disable error insight. That greatly
affects stability.
How do you do that?

I have disabled "together" because it was a memory and cpu hog and
crashed too
often to my liking.
--
Arthur Hoornweg

(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)
Atmapuri
2006-02-27 17:03:42 UTC
Permalink
Hi!
I have disabled "together" because it was a memory and cpu hog and crashed
too often to my liking.
I havent noticed this with D2006. You can disable Error Insight
in the Environment Options under Editor Options->Code Insight features..

However with Update #2 this may not be neccessary any more...

Best Regards!
Atmapuri
JED
2006-02-27 22:28:40 UTC
Permalink
Post by Arthur Hoornweg
I have disabled "together" because it was a memory and cpu hog and
crashed too often to my liking.
Together in D2006 is fine in my experience.
--
http://www.jed-software.com
http://jedqc.blogspot.com
Arthur Hoornweg
2006-02-28 13:43:34 UTC
Permalink
Post by JED
Together in D2006 is fine in my experience.
Not when you try to edit a very large unit.
Background activity is so high that each keystroke takes seconds to
register.
--
Arthur Hoornweg

(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)
Bruce McGee
2006-02-27 13:04:18 UTC
Permalink
Post by Alistair Ward
The issues we have are both compiler speed and stability. Ultimately
the stability is the major issue.
I'm surprised to hear that you're having stability issues. I know you
don't want to hear things like "works for me!", but I've been having
very good luck with it.

If you have any luck tracking down the cause and/or a work around, I
hope you'll post details here.
--
Regards,
Bruce McGee
Glooscap Software
Bruce McGee
2006-02-27 03:20:03 UTC
Permalink
Post by JED
We're starting a serious evaluation of Visual Studio, with a view to
rewriting in C++.
So the compiler performance isn't a big deal then?
Yeah, I thought that was funny, too.

"We don't like your build times so we're evaluating something with
notoriously slow build times. Take that!" It's almost Monty
Pythonesque :)

To be fair, the Delphi IDE has been slow for building, especially when
you have large project groups. This stopped being a problem when I
started using an external build tool for all production and most
testing builds.
--
Regards,
Bruce McGee
Glooscap Software
Joanna Carter [TeamB]
2006-02-27 07:26:22 UTC
Permalink
"Alistair Ward" <***@forum8.co.nz> a écrit dans le message de news:
***@newsgroups.borland.com...

| We're starting a serious evaluation of Visual Studio, with a view to
| rewriting in C++.

And you're complaining about slow compile times ? You'd better schedule your
compile times around lunch breaks :-)

Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
Steve Trefethen (Delphi R&D)
2006-02-27 20:17:12 UTC
Permalink
We believed the hype that Delphi 2006 had been done right, and got upgrades
for all our D7 licences. Incredibly slow compile times and very unstable...
Are the files you're trying to compile marked as read-only? If so, then
it's likely that the upcoming Update 2 could help you a lot. Regarding
IDE instability I think you'll notice if you read these newsgroups much
that you're likely in a pretty small minority regarding IDE stability so
and therefore I wouldn't rule out your setup being the issue. In order
to further help you, you'll need to provide more specifics about what
"instability" means (preferably in the .ide group).
For general information, our main application (a shrink-wrap 3D
visualisation tool) has nearly 9MB of source in over 300 .pas files. The
.bpg file contains 41 projects (5 exe's, and the rest bpl's).
For more help figuring out your performance problems contact medington
at borland dot com. He is a member of the development team working on
performance.
--
-Steve
Delphi.NET/C#Builder R&D
Borland Software Corporation
http://homepages.borland.com/strefethen
http://blogs.borland.com/stevet
Alistair Ward
2006-02-27 21:18:03 UTC
Permalink
Post by Steve Trefethen (Delphi R&D)
We believed the hype that Delphi 2006 had been done right, and got
upgrades for all our D7 licences. Incredibly slow compile times and very
unstable...
Are the files you're trying to compile marked as read-only? If so, then
it's likely that the upcoming Update 2 could help you a lot. Regarding IDE
instability I think you'll notice if you read these newsgroups much that
you're likely in a pretty small minority regarding IDE stability so and
therefore I wouldn't rule out your setup being the issue. In order to
further help you, you'll need to provide more specifics about what
"instability" means (preferably in the .ide group).
Yes, most of our source files are marked as read-only. I'll look forward to
seeing Update 2 to see what effect it has.

I know I seem to be in a minority re the stability issues, so I'm going to
persevere a bit longer to try to see what is happening.
Post by Steve Trefethen (Delphi R&D)
--
-Steve
Delphi.NET/C#Builder R&D
Borland Software Corporation
http://homepages.borland.com/strefethen
http://blogs.borland.com/stevet
Thanks,
Alistair Ward.
Charles McAllister
2006-02-27 22:03:12 UTC
Permalink
Post by Steve Trefethen (Delphi R&D)
Are the files you're trying to compile marked as read-only? If so, then
it's likely that the upcoming Update 2 could help you a lot. Regarding
Wow. I just marked all my source writable, and now the trial compiles every bit as mind boggling fast as Delphi 7! Thanks for posting the tip.
Steve Trefethen (Delphi R&D)
2006-02-27 22:38:06 UTC
Permalink
Post by Charles McAllister
Post by Steve Trefethen (Delphi R&D)
Are the files you're trying to compile marked as read-only? If so,
then it's likely that the upcoming Update 2 could help you a lot.
Regarding
Wow. I just marked all my source writable, and now the trial compiles
every bit as mind boggling fast as Delphi 7! Thanks for posting the tip.
Great. I'm glad this helped. I'll be expanding on this a bit more in my
blog (see below) so stay tuned.
--
-Steve
Delphi.NET/C#Builder R&D
Borland Software Corporation
http://homepages.borland.com/strefethen
http://blogs.borland.com/stevet
Jon Robertson
2006-02-28 03:03:45 UTC
Permalink
Post by Steve Trefethen (Delphi R&D)
Great. I'm glad this helped. I'll be expanding on this a bit more in
my blog (see below) so stay tuned.
Thanks for the insight, Steve. Ironically, I'm doing an in-house
training service on exception handling tomorrow. I'll be sure to
incorporate this info!

I already knew exceptions were slow. But this case highlights the
issue. In this case, they weren't even used for error handling. Just
if one condition fails, then try another. ;)
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
http://www.medevolve.com
Craig Stuntz [TeamB]
2006-02-28 12:49:41 UTC
Permalink
Post by Steve Trefethen (Delphi R&D)
Great. I'm glad this helped. I'll be expanding on this a bit more in
my blog (see below) so stay tuned.
Link:

http://blogs.borland.com/stevet/archive/2006/02/27/23540.aspx
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Borland newsgroup denizen Sergio González has a new CD of
Irish music out, and it's good: http://tinyurl.com/7hgfr
Vincent Parrett (VSoft Technologies)
2006-03-01 02:01:26 UTC
Permalink
Post by Steve Trefethen (Delphi R&D)
Are the files you're trying to compile marked as read-only? If so, then
it's likely that the upcoming Update 2 could help you a lot.
Hi Steve

Just read your blog and oh boy I'm looking forward to update 2. We just
moved our team over to D2006 (from D7) and our ide based compile times are
painfully slow(as in walk away and make coffee slow), thats with a project
group with 3 exe's and 50 packages.

Otherwise though I'm enjoying D2006 :)
--
--
Regards

Vincent Parrett
VSoft Technologies
http://www.finalbuilder.com
Blogs : http://blogs.finalbuilder.com
----------------------------------------
Automate your Build Process with FinalBuilder
Loading...