I realize, and apologize in advance for, the fact that this is an
off-the-wall problem... BUT

I converted an app to Delphi3 from Delphi1.

It has 4 main forms, one of which is a crude report writer.
I reads a table file, formats print lines and creates a print table
file.

There were hardly any conversion issues .. but when I run
the new version it runs half as fast as the old (31 sec vs 15sec)
formatting @ 1750 records.

This is on a 233 compaq .. what is worse the new version
takes 59sec on a toshiba laptop.

Are there any options settings for the compiler or BDE that
could cause this??????

This is not a major problem but is frustrating the hell out of me.

Thanks in advance for any assistance.

b j mahon
delphi rookie

I once tested with BDE and a very simple SQL sort Query on 250.000
records. Always D1 with BDE2.52 was 25..40% faster than D3 and
BDE 4.51.

So, 16-bit BDE _is_ faster, both on Win95 and NT4.0 plaforms, at
least in single user environments. But with your smallish dataset,
1.700 records, the 50% speed difference does sound strange.

Markku Nevalainen

The speed difference was noticed ever since Delphi2. The suspicion is that
16 bit apps get as much processor time as they take whereas 32bit apps get
as much as they are given.

If you try using the following :

function GetCurrentThread: THandle; stdcall;
function SetThreadPriority(hThread: THandle; nPriority: Integer): BOOL;
stdcall;

  THREAD_PRIORITY_LOWEST = THREAD_BASE_PRIORITY_MIN;
  THREAD_PRIORITY_BELOW_NORMAL = THREAD_PRIORITY_LOWEST + 1;
  THREAD_PRIORITY_NORMAL = 0;
  THREAD_PRIORITY_HIGHEST = THREAD_BASE_PRIORITY_MAX;
  THREAD_PRIORITY_ABOVE_NORMAL = THREAD_PRIORITY_HIGHEST - 1;
  THREAD_PRIORITY_ERROR_RETURN = MAXLONG;

  THREAD_PRIORITY_TIME_CRITICAL = THREAD_BASE_PRIORITY_LOWRT;
  THREAD_PRIORITY_IDLE = THREAD_BASE_PRIORITY_IDLE;

Ie.

 var
    th : thandle;
begin
    th:=getcurrenthread;
    setthreadpriority(th,THREAD_PRIORITY_HIGHEST );

you may notice an improvement, at the expense of the rest of the system,
that reflects a 16bit app's priority.

news:37ebc845.5924266@news.erols.com...

On Fri, 24 Sep 1999 18:58:29 GMT, be...@ix.netcom.com (bernard mahon)
waffled on about something:

I know exactly what you mean. I recently recompiled an app in D4 that
had been written in D3... Suddenly the .exe grew by over 20% in size,
although it doesn't run any slower.
Don't quite see how that can be. I could understand a D1 app growing
because of the extra overhead of the 32bit routines, but D3 and D4 are
both 32bit so surely the standard function routines shouldn't be that
different... Oh well, like they say, a program will alway require more
memory than is available to it!

As for your problem, I'm not that familiar with D1, I joined in with
Delphi quite late, at D3. But some pointers on speed.....

Variants.... Avoid like the plague... Very slow.
Use integers for numbers where possible.
D3 and 4 strings have no maximum length, so you may have code to deal
with long D1 strings you no longer need.

Hope some of this is of help,

Dodgy.

: be...@ix.netcom.com (bernard mahon) wrote:

In Delphi 1 you were allowed to bastardly and nastily hog all system
resources for yourself (and you did).

In Delphi 3, the OS does not give you a choice. You are being made a nice
guy. Thanks to that the graphics sub-system still works, other
applications may process their message queues and might - generally
speaking - be processing --- without you interfering.

Ok, this is vastly over-simplified, but you get the idea.

--
Stefan Hoffmeister    (http://www.econos.de/)
No private email, please, unless expressly invited.

This sounds a reasonable explanation why D1 apps would be so much faster.
But it sure is no merit for W95 or NT4.0 operating systems.

There was no other tasks running except the usual Windows destop, and then
the BDE SQL benchmark query. And yet WIN95 and NT keeps 40% of the system
resources and performance in some kind of reservoir, and only gives 60%
to the benchmark task.

How does NT4.0 work, if it is used as a network (file) server only? Does
it still skimp with the resources, and only gives some smaller portion,
not even near to 100%, for the of the servering process.

How I would like a good operating system to work is, that it would give
let's say 95% of the resources to active tasks. And even among them, more
resources for the busiest active task. And if new tasks are started, then
reallocate the resources according the new situation.

Markku Nevalainen

No. You talk about EXE size, the poster was talking about performance.

Have you looked at all the features that have been added to the core of
the VCL in Delphi 4?

--
Stefan Hoffmeister    (http://www.econos.de/)
No private email, please, unless expressly invited.

On Sat, 25 Sep 1999 12:36:47 +0200, no.s...@address.in.signature
(Stefan Hoffmeister) waffled on about something:

When I said I knew what he meant, I was referring to the probs you
sometimes get when you you move up from an earlier version of Delphi.
In my case my program bloated, in his it went slower.

Later on in my post I did include some speed relevant tips...

I know I'm not a great Delphi expert, but I was just trying to help
(there weren't any other replies when I wrote mine)

Take a deep breath, and calm down will you!

Dodgy.

Markku Nevalainen skrev i meldingen <37EC9DE5.2...@iki.fi>...

Interesting. Does this even apply to an app going in an infinite loop
where the Task Manager reports 100% CPU usage, or only when executing
more normally ?
--

Bjoerge

No one has asked yet, so I will. What were the compiler option settings in
both versions?

news:37ebc845.5924266@news.erols.com...

That 60% usage was just a quess. I even don't know if NT and Win95 even
gave all they had, I had no Windows measuring tools activated. This
thread was even the first time I heard one possible explanation for the
difference.

It's a bit strange that 16-bit code on pure 32-bit NT4.0 platform is
so much (25..40%) faster than the same code compiled under optimized
D3 compiler in 32-bit mode.

Maybe NT and Win95 are clever operating systems, when they automatically
limit the resources, how much each task will get. But at least there
should be ways how one could programmatically get all the power to
some critical task, if that is needed. I don't know if there are
such??

And so it always looks like 16-bit BDE SQL benchmark can beat
the 32-bit counterparts hands down.

Markku Nevalainen

Like SetPriorityClass?

--
Jeremy Collins
Kansai Business Systems
http://www.kansai.co.uk/

For those settings common to both versions .. they were the same.
Of those unique to Delphi3, there appeared to be nothing performance
related.

In a good operating system, you don't worry (or even think) about resources,
because there is no set limit on those...

Thomas Nagy
-----------------------------------------------------------------
Check out my cats! (http://members.home.net/2832779232/index.htm)
Free Office Suite: http://www.stardivision.com/so40/index.html

Is this referencing to Linux in some way?

I'm not sure how the Win resources are organized in the coming
Win2000. Is the operating system there always able to clean all the
unused {*word*99} from memory, no matter how bad code the programmer
makes.
NT is more forgiving with resources than Win95/98, but this may
give the programmer the freedom to write worse performing code also.

I wonder how this is done in Linux then? How does the operating
system know which memory areas it is safe to clean now. And are the
resources really unlimited there, no limit for any GDI stuff or
anything? If all the RAM gets full, then the disk space will be
used, etc.

Markku Nevalainen