Search the Community

In my experience you get what you pay for. None of the free profilers has ever worked satisfactory for me. I would recommend AQTime or VTune but they are both a bit expensive. I prefer VTune but as it doesn't support Delphi debug info it's only suitable for asm level profiling. It's excellent for that though.

It is fast, i always profile and benchmark, but IMHO both benchmarking and profiling results have accuracy problems when parallelism involved, the result start to get far from the expectation specially when strings involved, and here there is a little what can be done, for that i found timed and repeatable stress test can also be used to measure the code optimization for multi threading . By little can be done: i am pointing to MM involvement in handling strings with the amount of repeated thread contention.

We have been using Delphi in a VMWare Workstation for over a decade. We have a team of about 12 people. Some remote workers use Delphi in a Citrix instance run on our XenDesktop environment. A decade ago, there were lots of problems. Windows activation issues. Delphi activation issues. etc. But we stuck with it because it ensured all team members have an identical instance set up appropriately. Also, if one computer crapped out, we were up and running within 20 minutes. These days, its a no brainer. We dont even have Delphi installed directly on the host machines any longer, so I cannot compare to a host installation on the same machine, but running in the VM is more than acceptable. All benchmarks we have run (i.e. running same executable inside vm and on real machine) are within 95% speed of each other. For profiling, we dont even both copying to the host machine any longer, unless we are profiling heavy multi-threaded work. What does make a big difference is to put the VM on an SSD. Compile times are much faster. Our App is about 2 million LOC, but we ensure that our individual units are not too large. Usually a few K LOC, up to a max of 20K LOC or so. CTRL+END is pretty instant for me, even in the largest units. Maybe we would get 1/2 sec better on some mouse actions if we installed it on the desktop, who knows, but I personally do not notice any speed impediment due the to the VM. My typing speed is usually the bottleneck, not the IDE (and I type pretty fast).

It is never a good idea to increment the size by one. See this blog post: Extending arrays But otherwise: yes, you are being too pedantic. If this is in a tight loop, you might think of profiling which is faster, otherwise, it doesn't really matter. FWIW, I would do it like this (after Delphi XE7, IIRC): NewRecord.SomeField := SomeValue; // etc... MyArray := MyArray + [NewRecord]; No need for SetLength, Len or High

- About the IDE, on Windows I use the VS Integration most of the time, because on my machine it is open always. On Mac I'm using there Fire IDE and I like it. It is different but really fast. - Native CPU is fast but I have not done any profiling. To be honest if you look what the net runtime is doing, there is not more any reason to discuss "native" versus "CPU". But if you have more Questions let start a new thread, because we are now really off topic here

"Did you measure it?" 🙂 I can confirm that sorting at the end is faster. Before we start guessing, however, you should do some profiling.

Greetings! In true Black Friday style, we are having a 50% blitz sale on new licenses of all our products, from now until the end of cyber monday! If you have been looking for a great Delphi database, look no further than NexusDB. The latest source version already supports Rad Studio 10.3 Rio, which was released today. For the best profiling and quality assurance tools for Delphi projects, Nexus Quality Suite is the one to get. At AUD225 (rebated) it is a steal. Web shop: https://www.nexusdb.com/support/index.php?q=pricing To qualify for the discount, make sure you enter the coupon code BLACKFRIDAY during checkout. New licenses only, and note that buying multiple licenses simultaneously also gives an extra rebate. regards, The NexusDB Team