Leaderboard

If you really worry about performance in this area then don't use TCriticalSection but embed the TRTLCriticalSection (or the appropriate thing for POSIX) into the object where you need it - that way you also eliminated an indirection. And make sure that your allocated memory from the memory manager is aligned cacheline friendly (it won't by default)

Better Translation Manager https://bitbucket.org/anders_melander/better-translation-manager The Better Translation Manager (BTM) is a replacement for the Delphi Translation Manager a.k.a. the Integrated Translation Environment (ITE) and External Translation Manager (ETM). Why is it better? Well, for one thing, it's free but more important; It actually works - unlike the ITE/ETM. Why? The standard Translation Manager that ships with Delphi today was originally an individual product known as the Borland Translation Suite. With Delphi 5 it became a part of the enterprise edition. The Borland Translation Suite showed great promise but unfortunately it never evolved from its roots as an external tool and has always been hampered by severe bugs that made it completely unusable in practice. As a result nobody uses it. This can be witnessed by the plethora of homegrown and commercial alternatives. The great benefit of the standard translation system is that it just works (this is the system itself I'm talking about, not the tools. The tools suck). Apart from the requirement that you must use resourcestrings you don't need to do anything special when writing your code. At run time you just place the compiled resource modules in the same folder as your application and the Delphi Run Time Library automatically takes care of loading and using the translations based on the current Windows user interface language. Anyway, since Embarcadero has now finally admitted that they are never going to fix the Delphi Translation Manager and instead recommend that we find alternative solutions, I decided that it was time I solved this little problem once and for all. The core functionality of the Better Translation Manager was written in two weeks during my summer vacation in Italy 2019. Amazing what you can do with a little pasta! Features Does not require any changes to the source code of the application being translated. Works with the existing standard Delphi localization system. Translates resourcestrings and all strings in forms regardless of any 3rd party components used. Works on compiled application. Source code is never used. Generates localized binary resource modules (resource DLLs). Does not use an external compiler. Can import existing translations from compiled application and resource modules or from XLIFF localization source files (dfn, rcn files). Read and save TMX and TBX translation memory files. Import Translation Memory from TMX (Translation Memory eXchange), TBX (TermBase eXchange), Microsoft Glossary and CSV. Machine Translation using Translation Memory, Microsoft Translation Service or Microsoft Terminology Service. Forms, Components, Types and Values that should be ignored can be specified in a Stop List. Translations are Spell Checked. Validation Rules to catch common translation mistakes. Supports Right To Left (RTL) editing based on translation language. Translation project is stored in a single XML file. Command line interface for use in automated build systems. Fast! Refreshing a large project typically takes less than a second vs. many minutes with the ITE/ETM. Supports all Unicode versions of Delphi (i.e. Delphi 9 and later). Resource modules contain the version resource of the source application. What it doesn't do There's one task that BTM, by design, doesn't attempt to solve: Localizing the placement and size of controls. Since it has been my experience that it is a far better idea to design the user interface in such a way that the layout automatically accommodates changes in font- and text size and shorter/longer texts due to translation, I decided from the start that I would not be supporting localization of size and position of controls. This also relieved me of having to create a run time form designer, supporting 3rd party controls visually (something that nobody so far has managed to find a foolproof solution to) and deciding what individual properties constitutes size/position values. Instead I just localize all string values - and only string values. But wait... There's More! Yup, you not only get this little wonder for free. You get the full source code too. Grab it at the repository linked at top. More details at the repository. Enjoy / Anders Melander

Secret ? no, they're publicly published (agner, intel/amd doc, optimization guide, paper, LLVM, ...). I read them and experiment things my self and when I have no things to do I compare results on different compilers. Sometime, when I'm lucky, I find an already benchmark that lists the results. Error happens a lot specially when porting code from/to another platform ... but I deeply inspects the error and try to learn from it : why it happened ? a workaround ? how to avoid it?.

Perhaps I didn't explain it well enough. In case my code contains a check like: {$IF CompilerVersion < RAD_Chicago} {$IFEND} {$IF CompilerVersion < RAD_Sydney} {$IFEND} {$IF CompilerVersion < RAD_Rio} {$IFEND} that may perfectly compile with a future Delphi version named Chicago incorporating constants RAD_Chicago = 63; // no offence ... RAD_Sydney = 34; RAD_Rio = 33; ... but fails with any compiler available today. So I still need this one file with all these declarations and independent from the compiler. Where would be the benefit of Delphi providing a bunch of different versions of such a file where most of them are probably outdated and thus useless? Imagine we have each Delphi version in a separate VM, where almost all of these don't have the latest version of this file. Getting all this working will result in way more hassle than having this file maintained in one place, copying that into each project that makes use of it and keeping it up to date with each new Delphi version.

You can create that from within the IDE: Component | Import Component | Import a Type Library

No, it's not the same codegen, its a test and jnz less. You don't want forward jumps taken in the common case. Also a very important fact (I think it was mentioned before) - depending on where the compiler puts the code the hot loop code might cross cache lines - that slows things down significantly and can happen when you add or change unrelated code in other routines or in this routine - such as a check for Length or similar. When I let the routine start at some 64byte aligned address the loop body will cross cache lines and be slower. To my knowledge there is no way to control the alignment of generated executable code so that you can force hot code into a single or as few cache lines as possible.

@Mahdi Safsafi My experiment with the Delphi compiler and pointers is not the same as yours. In mORMot, I ended up with using pointers (PUTF8Char=^AnsiChar) for the raw UTF-8 processing, which generated faster code. Of course, pointers are difficult to deal with - you need to know what you are doing. I always consider pointers by looking at the generated ASM. If the code is better and runs faster with pointer, then I use them. Otherwise I don't. I am biased for sure: I like pascal because it can be both high-level and modern (like Java/C# - with high-level structures like classes, strings or dynamic arrays), and also system-level (like C). Pointers are clearly for the 2nd level. Anyone don't like pointers? Don't use them. But they are pretty convenient and efficient for low-level processing, if the goal is performance. I like very much when you paternize me with the Gather-scatter pattern. You can perfectly do Gather-scatter with two pointers. This is called pointer arithmetic - which I use extensively in mORMot. So I don't understand what you are talking about.

Yep, I always wondered why so many people use concrete version defines that make the whole code unusable when a new version arrives. I personally prefer minimizing usage of version defines replacing them with defines that declare the very feature. F.ex., RAD_2010 => GENERICS_OK (non-buggy generics). It's like using logically named identifiers instead of i1, jj3 etc

Don't use regsvr32 - that's for in-process servers. You can't use task manager to verify that you server is being executed (it terminates as soon as it finishes registering) but you should be able to verify if your server has been registered by looking in the registry. If you don't know where to look then you need to read some docs on msdn. COM is a nightmare if you don't understand how it works. Anyhow, try this: Run Delphi as as administrator. Enter /regserver in Run|Parameters Place a breakpoint in TComServer.Initialize (in the System.Win.ComServ unit). Run your server in the debugger. You should now be able to trace through TComServer.UpdateRegistry and verify that it ends up registering your type library and your COM classes (probably via TComObjectFactory.UpdateRegistry).

I would use the TRTLCriticalSection which is a record defined in Windows.pas. TRTLCriticalSection = record DebugInfo: PRTLCriticalSectionDebug; LockCount: Longint; RecursionCount: Longint; OwningThread: THandle; LockSemaphore: THandle; Reserved: ULONG_PTR; end; A record helper is provided in SynchObjs.pas TCriticalSectionHelper = record helper for TRTLCriticalSection procedure Initialize; inline; procedure Destroy; inline; procedure Free; inline; procedure Enter; inline; procedure Leave; inline; function TryEnter: Boolean; inline; end; According to Eric It is much less prone to this issue (I don't have the reference though) and does not incur the overhead of object creation/destruction. The SpinLock is another option. So is the Windows Slim reader writer (SRW) lock. And of course you can use TMonitor which nowadays is comparable in performance to the CriticalSection. (SpinLock and SRW locks are faster). For anyone interested here is a record wrapper to SRW locks. (* Multiple Read Exclusive Write lock based on Windows slim reader/writer (SRW) Locks. Can be also used instead of a critical session. Limitations: non-reentrant, not "fair" *) TSlimMREWSync = record private Lock: TRTLSRWLock; public procedure Create; procedure BeginRead; procedure EndRead; procedure BeginWrite; procedure EndWrite; function TryRead: Boolean; function TryWrite: Boolean; end; { TSMREWSync } procedure TSlimMREWSync.BeginRead; begin AcquireSRWLockShared(Lock); end; procedure TSlimMREWSync.BeginWrite; begin AcquireSRWLockExclusive(Lock); end; procedure TSlimMREWSync.Create; begin InitializeSRWLock(Lock); end; procedure TSlimMREWSync.EndRead; begin ReleaseSRWLockShared(Lock); end; procedure TSlimMREWSync.EndWrite; begin ReleaseSRWLockExclusive(Lock); end; function TSlimMREWSync.TryRead: Boolean; begin Result := TryAcquireSRWLockShared(Lock); end; function TSlimMREWSync.TryWrite: Boolean; begin Result := TryAcquireSRWLockExclusive(Lock); end;

a silly question, IMHO this forum layout should be optimized leaving more space for the topics

Open cmd, type dcc32 it prints (almost) all parameters. You will find the -NS switch for namespace search path. So what you do is pass -NSvcl (probably there are some more needed such as Winapi - just take those that a new project in Delphi usually gets)

Plenty, this is my current gui of choice - https://git-fork.com/

New version released: v1.0.7271.54299 http://melander.dk/download/amTranslationManagerInstall-1.0.7271.54299.exe Changes since v1.0.7254.4932 New features: GNU GetText PO file import. Improvements: Copy to clipboard not uses tab delimited CSV for better integration with Excel. Normalization rules can now be configured. New validation rules: pipe | and surround ()[]{}<> mismatch. Validation warnings can now be dismissed and resolved. New equalization rules: Leading space and Trailing space. Duplicates in Translation Memory lookup results are now ranked by the similarity of the translation source to the value being looked up. Other: Installation of the command line tool is now optional. Primarily because it is currently being flagged as a false positive by several virus checkers. Removed dependency on midas.dll A slew of performance and usability improvements and bug fixes. Thank you to all those that have sent me suggestions, feedback and bug reports.