Dalija Prasnikar

Word of caution, TLightweightMREW is not merely a lightweight equivalent of TMultiReadExclusiveWriteSynchronizer as it has different behavior. Most notably, write lock is not reentrant on TLightweightMREW and acquiring write lock from the same thread twice will cause deadlocks on Windows platform and will raise exception on other platforms. When it comes to TMultiReadExclusiveWriteSynchronizer it is implemented as MREW only on Windows and on other platforms it is exclusive lock.

You would need to call method at the beginning code that runs in a thread that would add that thread ID into dictionary and create cache instance for that key. At the end of the thread code you would also call method that would be responsible for removing that key and cache from the dictionary. This add/ remove logic should be protected by some locking mechanism contained within TBSItemProvider instance and protected with try...finally block so that cleanup is done in case code in between raises an exception. If you share other data within that instance between threads then any such access should also be protected by a lock, unless all threads are only reading the data.

Those are fields in a class, threadvar is only supported for global variables. There is not enough context around what you are trying to do, so it is hard to say what is the most appropriate solution. From how it looks now, I would say that what @David Heffernan proposed looks most suitable. You would have to create and remove items in the dictionary when thread is created and destroyed. Another question is, are you sharing other data within TBSItemProvider instance between threads which sounds like you are doing, and what kind of protection you have around that data. If it is not read only then sharing data is not thread-safe.

I don't know the details of their setup or the migration process, but it definitely took much longer than it was initially expected. If I remember correctly this coincided with the server outage, so it is possible that this also had an impact. This is right on the mark.

They most likely stayed with JIRA because their internal system also uses JIRA and even moving that internal JIRA to the cloud was significant effort, moving to something completely different would probably be more troublesome. Not to mention other possible differences in workflow. Yes, JSM sucks big time, but this is because Atlassian made subpar product.

I had zero problems with Delphi 7 in modern environment. I still have it installed on Win 10. Works like it always did. I even used it in production until few years ago - I have my own installer and to keep it small I used Delphi 7.

It is hard to say which version is the most suitable and most usable because that will always depend on your code. If you are not using particular features then bugs in those features will not have any impact on your work although they may be showstoppers for others. But historically, Delphi 7, 2007, and XE7 were pretty solid releases. For newer ones, it is hard to say as there are plenty of changes and improvements in various areas, but also some issues. So it really depends on what you are doing.

Stack Overflow Developers Survey for 2024 is live https://stackoverflow.com/dev-survey/start Let's put Delphi on the map

NativeInt is 64-bit on Win64 so Integer overload is not appropriate (too small) there. If you want to force it to Integer overload you will have to typecast Integer(NewLine.Count - 1)

The only correct answer is to write Oranges

I don't know. The question is what do you get when you try enabling Vulkan. Do you have aliasing problem with Vulkan, too? Each of those checks uses completely different rendering technology. So Skia Raster canvas is a different one from Skia Vulkan.

How it works when you UseVulkan? I have done some experiments and the fallback for Skia is OpenGL while FMX without Skia uses Direct2D. I am getting much better performance with Vulkan on Windows.

What are your exact settings when the drawing is slow on Windows? All GlobalXXX values you are using?

If all Macs work fine, then this is not due to tile based rendering (or at least not significantly), probably unified CPU/GPU memory is more relevant here. Another possibility would be that there is some difference in FMX platform specific code. But I cannot comment on that as I never looked at it.

The question is whether they can do something about it at all. For start, Skia in Delphi operates on several layers of indirection (including some poor design choices) which also involve memory intensive operations on each paint (including reference counting). When you add FireMonkey on top that is additional layer. Now, all that does make Skia slower than it could be. But that problem exists on all platforms. ARM and especially Apple Silicon have better performance when it comes to reference counting, but that is probably still not enough to explain the difference. Some of the difference can also be explained with juggling memory between CPU and GPU on Windows as those other platforms use unified memory for CPU/GPU. However, my son Rene (who spends his days fiddling with GPU rendering stuff) said that from the way CPU and GPU behaves when running Skia benchmark test, that all this still might not be enough to explain observed difference, and that tiled based rendering on those other platforms could play a significant role. Another question is how Skia painting actually works underneath all those layers and whether there is some additional batching of operations or not. @Hans♫ Do the Macs you tested it on have Apple Silicon? If they do then they also support tile based rendering. As far a solutions are concerned, it is always possible to achieve some speedups by reusing an caching some objects that are unnecessarily allocated on the fly, those could be both in FMX code itself, or in how FMX controls are used and how many are them on the screen. I used to create custom controls that would cache and reuse some FMX graphic objects when painting instead of creating complex layouts with many individual FMX controls.

Even with class helpers available, I had to edit VCL source code in few places. And I still had to make a completely new implementations for plenty of stuff. Now, with time some things get fixed, some get improved, but there will always be things for which you would either need class helpers, which are no longer available.

Well, that discrepancy could have been solved with 1-based arrays. Delphi wouldn't be the first nor the last language having them. See: https://stackoverflow.com/q/9687039/4267244

That is in no contradiction with what I said, as TP started as extension of Standard Pascal. Anyway, 1-based string types never caused any problems until they introduced 0-based strings for mobile compilers and the whole hell broke lose.

This was due to Turbo Pascal legacy.

Each core has its own FPU. It is possible that some older multicore processors shared single FPU, but even in such case each thread would have access to its own "FPU data copy". If those values would be shared among threads, then different threads could trample upon results of other thread calculations.

FPCR is part of the FPU and its state is preserved during context switch. So each thread works with its own state that is independent of others. If you only handle floating point state directly through FPCR it will be thread-safe. Problem with Delphi is that it throws global variable into the equation and then handles FPCR with the help of that global in thread-unsafe manner, which can then leak "wrong" state into different thread.

FPCR can be set in a thread safe manner. it is just that Delphi RTL doesn't do that on Windows platform. David has written about it see and https://stackoverflow.com/a/27125657 I have also written about it in my book Delphi Thread Safety Patterns. Working with masked FPU exceptions is the norm across various languages. Also even before Delphi 12, all other Delphi platforms except Windows VCL has masked FPU exceptions. So if you had written FMX application it would have been working the same way it is working now across the board. So the best option is moving to the masked FPU exceptions as this will create the least amount of trouble for the future. Of course, if you are dealing with Delphi built DLLs which don't honor that, you will have to adapt. Another option is to unmask exceptions and proceed as usual, but doing that in multithreaded application is not advisable unless you also patch the RTL as it is not thread-safe. Even having masked FPU exceptions is not thread-safe, but it is much harder to trigger the issue and much easier to avoid RTL API that uses unsafe parts than with unmasked exceptions.

Well, the problem is technically in the LLVM, so blaming the LLVM is fine 😉 But again, also it is not technically a bug in LLVM, but merely lack of certain feature, which is not so easy to add at this time.

It is language related, more precisely compiler related (LLVM backend). The hardware part is related to exceptions that happen in hardware which cannot be caught by LLVM backend. Old Delphi compiler (Windows one which has custom frontend and backend) can catch those because it was designed that way. LLVM origins are in C++ which on language level does expect catching such exceptions, so there was a "design mistake" in there that is now very hard to change, to accommodate slightly different languages. Most common hardware exceptions are access violations (accessing nil or invalid memory) and floating point exceptions. See: https://dalijap.blogspot.com/2023/12/catch-me-if-you-can-part-ii.html Plenty of languages are designed around notion that if they encounter certain types of issues they should just crash the whole application instead of trying to recover. Now, such behavior reduces the chances of certain vulnerabilities, but on the other hand makes very hard to deal with certain scenarios, especially gracefully detecting and handling bad input data, and they put a lot of more pressure to the developer to imagine all kinds of potential failures and prevent them explicitly in code. So in Delphi (Windows platform) accessing nil pointer will result with exception which you can catch and handle, so you can write code that will not check for nil instance and just try to access it and if it fails you can have exception handler that will handle such situation without anything bad happening. On the other hand, if you have such code in Swift (which also uses LLVM) your application will crash and burn and you cannot recover from such error at all. You need to pre-emptively check whether instance is nil when you expect it might be to avoid accessing nil instance. In Delphi compilers with LLVM backend, you can still catch nil instance access and recover, you just cannot catch it in the immediate code block, but it must be in separate procedure or method and only outside exception handler can catch and gracefully handle such exception.

I would use TypeInfo instead of RTTI as it will be faster. This requires System.TypInfo procedure TMyThingy.SetEnumPropertyValue(const AValue: string); begin PByte(@FEnumProp)^ := GetEnumValue(TypeInfo(TMyEnum), AValue); end; You should pay attention on enum type size and use appropriate sized pointer when casting PByte(@EnumProp)^. This will also raise out of range exception if passed string does not match to any value in TMyEnum. You can catch that and set it to some default value if needed.