Search the Community

I can't be more conflicted between these both phrases, yet both are quite true and right. One thing though, Embarcadero should hire more experienced .NET developer to build the IDE right ! I saw some discrepancy in the .NET part of the IDE, which is big part of it, something wrong with performance counters, like they been left on and had been forgotten and untouched since Delphi 2009 (at least) to Seattle (at least), i can't be sure, but there is something wrong in that part, the memory usage and the calling stacks keep pointing that code built for profiling not for production, that behaviour is not observed in other .NET applications, and yes the RAD IDE eligible to be called .NET application.

Again, with no knowledge of content, it is impossible to speculate. If one row per record, you are talking about roughly 60 pages, and though we always want things to be fast, 15 seconds for 60 pages doesn't sound terrible. You need to do some profiling. Also isolate the timing of the report production from any data preparation. Lacking any detailed knowledge of your code, we can offer no specifics.

No, not using any of it, yet. Planning to do some profiling and benchmarking on real data and will see if there are any bottlenecks in this area.

You will not see it, not like that, because that is very hard to measure, the magnitude may range between 0 and few cycles ( but in fact it might measure minus few cycles also), so out-of-order-execution is a complicate matter, and what i wrote above above is fraction of how it does work, because it does need the compiler assistance to make sure the assembly code is helping to create better chance for the CPU to use it. explaining in example will be better, also the internet full of resources about this subject, but i found this on SO, which does have 2 nice and accurate answers https://cs.stackexchange.com/questions/97407/difference-between-delayed-branches-and-out-of-order-execution One more fact the compiler should be aware of those situation and utilize different registers to help the CPU execute out of order instructions, Which Delphi compiler is helpless here. Now to see it in work you should create test/profile case that use low level timing directly from the CPU itself (use the RDTSC instruction), then time that part, as we all have modern CPU's, most likely your CPU is having some technology like Speed-Step, so go to the BIOS and disable it, then time again to establish a base line, after that only you will get better idea if out-of-order-execution is been used there, here we need the actual speed from the CPU as it built without those enhancement, We are not talking about slower performance, but we might get better performance by helping the CPU to decide and execute bunch of instruction at the same time. One more thing about profiling, if your timing ranging, means not 100% exact result ( like 1.23456 second every single time) , then you need to make sure that all CPU enhanced technology are disabled first ( Speed-Step, Hyper-Threading...), if you still get ranging result then make sure to switch to use Fibers instead of Threads, Fiber will not be interrupted ( less interaction from the OS) it will have less chance to suffer from a context switched before yielding, such you will get stable result, after that enable those enhancement, and change between jumps/branching to measure what was the result. In other words unless you have same result from each and every execution without these CPU enhancement, then measuring the speed with them is invalid. Yes and no, 2 cycles here with additional few in case out-of-order-execution is triggered and helped, might looks negligible but think of it differently, it is RTL and it is on every Delphi application working over the globe, simply put why not ?, imagine how many cycles been wasted since Delphi 2007 as the OP mentioned, RTL is not something you change every day and it should be best of the best, the number of cycles can be saved is literally unimaginable number, right ? now imagine you can squeeze 2 cycles from most RTL procedures !! On other hand what is the cost of having better and faster RTL ? nothing, it is there and will be there for ever, it should be evolving in that part, hiring or outsourcing that part to real professionals knows how things should be done is most likely cheaper than visiting new city for marketing festival. On side note: i have simple example which will show this out-of-order-execution with SIMD instructions that might raise your eyebrows, not sure to put it here now or later after dummzeuch agree to steer the subject away, dummzeuch looks like nice guy, he is not Daniel, he is not Lars , those guys are traumatizing material.

FWIW I have done similar but in many cases just looking at the disassembly does not tell the entire story - running the code and profiling it (which can be a very tedious process given the many different uses cases etc) will often tell a different story and modern hardware architecture just shows you the middle finger. Especially for routines that get inlined in many different places although they might produce a little bit better disassembly it might not be worse or even better in some cases to not inline them if they can be written jump free because the code will be smaller and likeliness of staying in the instruction cache will be higher. But again we are talking about microoptimization here that requires a lot of profiling and looking at some cpu metrics.

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