Subject: Executable run speed

[user5]

    I have a 32-bit program that runs fine on a 64-bit computer except for one particular process which does some
simple graphics stuff on TImages. I'm almost certain that this process also used to run fast on the same 64-bit
machine but now it doesn't.
    In Project Options for the program the Strip Symbols checkbox is not checked and the program is not being run
in compatibility mode. I don't remember changing anything in the program.
    Does anyone have any ideas?

[Martin_fr]

There a lots of possibilities.

For starters the speed is not only the code, but also depends on the data. Different data, leads to different mem allocs, and can affect cache hits/misses.

Also the same code may run faster/slower if it is moved a few bytes. That happens, when other code in other procedures grows/shrinks. That too is a cache issue, but not the same cache. Some internal microcode cache in the the cpu. For that try {$codealign loop=32}  and/or {$codealign proc=32}
... Though I don't know how that affect 32bit assembler.
And that can go either way, better, worse or keep the same.


Not sure if MS defender may get into the way... It may see 32 bit code as unusual and interfere more.


Probably a ton of other stuff...

[user5]

    While it's true that I haven't changed the code that is running slow, it is true that I have changed the code
elsewhere in the program.
    I put the directives in that you suggested and the program runs okay but it didn't fix the slow running problem.
    I've been doing some research on this subject but I haven't found anything yet that fixes this issue.
    Thank you so much for trying to help me.

[Martin_fr]

Unless you have a repository and can roll back until you find the change that triggered it....

Maybe just try to find out how to improve the speed without looking at what might have been in the past.

If you are on Linux (or if you can testrun on linux, and get the same issue), then there is a tool called "valgrind".

valgrind --tool=callgrind  yourapp

and then that produces a datafile that can be viewed with "kcachegrind", and tells you how much time was spent where. So then maybe you can find the culprit.

If you do, also search the docs for inst-at-start. Since you don't want to analyze all your code, but only the code running whatever task has slowed down.


Otherwise start putting writeln/debugln into your code, and gettickcount64 and narrow it down. But that is a hell lot of work.

There are a few other profilers, but I haven't worked with any of them. So I can't tell you much about them. (don't even recall the names)