Steve Maughan

Hi Gunther, Thanks - I'll take a look. This solution seems to use an ActiveX control. I was hoping to access via WinRT. Cheers, Steve

Back when Rio was initially launched I remember Marco mentioning it now supports Windows Pen / Ink. This would enable apps to use the Surface Pen. I can't find anything in the documentation. Does anyone know of a demo of how to use the Surface Pen with Delphi 10.3? Thanks, Steve

No LLVM optimization is really disappointing. If you wind the clock back to 1995, many of the early developers coming from VB3 were exited about a compiled executable that ran at the same speed as "C" programs. They wanted and valued fast executables. Borland / Codegear / Embarcadero have each ignored this value their developers place on fast code and haven't improved the code optimization for 20 years. It seems they take a, "it's good enough" view. I'd encourage them to invest some time and include all the optimizations that LLVM offers (even if it slows down compilation speed for the Release Build). I think they'd be surprised at how well this would be received by the Delphi community. Steve

Is the new release (10.3.2) component compatible with 10.3.1? I'm seeing some component vendors (e.g. DevExpress) say their latest release supports 10.3 (i.e. no mention of the ".1" or ".2"). This implies it will install components into 10.3.1 and 10.3.2. even thought this version of their components was released before 10.3.2 Can anyone confirm? Thanks - Steve

Have they done that? Why would they do that? Thanks, Steve

Ugh!!! Thanks for sharing

Hi David, I'm certainly not an expert in this field. Over the years I've seen various speed benchmarks that suggest Delphi's Windows compiler produces executables that are significantly slower than those produced by the top C++ compilers (e.g. Intel). In the chess world (where I am an expert) the rule of thumb is a Delphi version of a chess engine will run about 30% slower than the C++ equivalent code bases (Critter is the engine that was developed in two parallel code bases). Let's face it, there doesn't seem to have been any work done on optimizing the code created by the Delphi compiler in the last 20 years. I'm just hoping the new backend will be better. Thanks, Steve

Since the new MacOS compiler is based on LLVM I'd be interested to see any executable speed comparisons against Delphi Win 64 compiles. Won't the LLVM based compiler produce executables that run significantly faster? Or am I being too optimistic? Steve

Apparently the new macOS Delphi compiler is based on the LLVM compiler. I wonder if future Delphi compilers for Win32 / Win64 will also be build on top of LLVM? Would this improve the speed of the final executables? Steve

Are you sure? As I said above, in AlignMix I render a TBitmap.Canvas for each layer of a map using one worker thread per layer. It's rock solid, no crashes or resource issues when rendering. Steve

Hi Stefan & Peter, Thanks! I'm assuming most users will have a two or four core system. But power users may have 64 cores; it was really them I was thinking about. Truth is, I need to stop optimizing at this stage and focus on the actual algorithm. Thanks again, Steve

I'm considering ways of speeding up an algorithm. One option is to add parallel "for loops". I can certainly add a single parallel "for loop" and get a speedup. The algorithms effectively has nested "for loops" and I could also make the inner "for loops" parallel. Is this a advisable or are nested parallel "for loops" a big no-no? Or does it depend on the number of levels of nesting e.g. one inner parallel loop may be ok, but more would be bad? Thanks, Steve

In my app (AlignMix - a mapping package) we draw the map in layers (e.g. one layer may be road, another towns). Each layer is rendered by its own thread. We then "smush" all the layers together to get the final image. It works well, so clearly it is possible to draw on a TCanvas in a thread as long as no other thread is drawing on the same canvas. Steve

FlexCel also read / writes CSV files

HI Stefan, You may well be right. I need to test. Thanks, Steve