Leaderboard

Well, it was the last option 😉 As the example shows, this pattern hiding something from you. It's not your friend. Do not underestimate that. With time, you won't remember everything. I mean, a thing. You won't remember anything. 😉

ANN: StyleControls VCL v. 5.05 just released! https://www.almdev.com StyleControls VCL is a powerful, stable package of components, which uses Classic drawing, system Themes, GDI+ and VCL Styles. This package contains the unique solutions to extend standard VCL controls and also has many unique, advanced controls to create applications with UWP / Fluent UI design. Also with this package you can really improve applying and using of VCL Styles in your application. In the new version, we tested the library with RAD Studio 11.1, added new features that customers requested + some fixes.

SFML Simple Fast Multimedia Layer Bindings that allow you to use SFML and other useful C libraries with Pascal. Included CSFML (https://github.com/SFML/CSFML) pl_mpeg (https://github.com/phoboslab/pl_mpeg) Nuklear (https://github.com/Immediate-Mode-UI/Nuklear) physfs (https://github.com/icculus/physfs) minizip (https://github.com/madler/zlib) SDL (https://github.com/libsdl-org/SDL) Minimum Requirements Windows 10+ (64 bits) Delphi Community Edition (Win64 target only) FreePascal 3.2.2 (Win64 target only) Usage Add SFML to your uses section to access all the aforementioned libraries. You link to SFML dynamically by default and will look for the SFML DLL in your application path. You can also call InitSFML, before any other routine, with a the path to the DLL location. Define SFML_STATIC in SFML.pas to statically link to SFML and the DLL will not have to be included in your application distro. InitSFML will have no effect and you can leave it in your sources so that you can switch between static and dynamic linking during development. uses SysUtils, SFML; var Mode: sfVideoMode; Window: PsfRenderWindow; Event: sfEvent; Music: PsfMusic; begin Mode.Width := 800; Mode.Height := 600; Mode.BitsPerPixel := 32; Window := sfRenderWindow_create(Mode, 'Hello SFML', sfResize or sfClose, nil); Music := sfMusic_createFromFile('arc/audio/music/song01.ogg'); sfMusic_play(Music); while sfRenderWindow_isOpen(Window) = sfTrue do begin while sfRenderWindow_pollEvent(Window, @Event) = sfTrue do begin if Event.kind = sfEvtClosed then sfRenderWindow_close(Window); end; sfRenderWindow_clear(Window, DARKSLATEBROWN); sfRenderWindow_display(Window); end; sfMusic_stop(Music); sfMusic_destroy(Music); sfRenderWindow_destroy(Window); end. Support Issues Discussions SFML website SFML on YouTube

That depends. Our internal programs all do that. They aren't installed under program files, though.

No I don't think so. Follow the actual rules. When you create an instance, destroy it in the same context that you created it.

My frontal lobe Latency is one-two minutes L1 cache. one to two weeks L2 cache every else is water under the bridge. excepting a few grudges. 🙂

There's no one perfect way that everyone should use. Personally, I use two different approaches: If a program uses a database, I keep all the configuration settings in there except for the path/server/port of what is needed to connect to the database and those are set in an .INI file in the same folder as the application during installation. The installer has admin rights so it can create files under Program Files, and the database settings should never be changed--except by an administrator. In this case the INI filename is simply: ChangeFileExt(Application.ExeFilename, '.INI') If a program doesn't use a database and has several options to configure when the program is in use by regular users, the INI filename is: FAppDataPath := TPath.Combine(TPath.GetPublicPath, ChangeFileExt(ExtractFileName(Application.ExeName), EmptyStr)); ForceDirectories(FAppDataPath); FAppConfigFilename := TPath.Combine(FAppDataPath, ChangeFileExt(ExtractFileName(Application.ExeName), '.ini')); This puts the file in a folder under %ProgramData%\MyApp making it global for any users on the computer.

Don't expect anything magic by using mORMot MoveFast(). Perhaps a few percent more or less. On Win32 - which is your target, IIRC the Delphi RTL uses X87 registers. On this platform, MoveFast() use SSE2 registers for small sizes, so is likely to be slightly faster, and will leverage ERMSB move (i.e. rep movsb) on newer CPUs which support it. To be fair, mORMot asm is more optimized for x86_64 than for i386 - because it is the target platform for server side, which is the one needing more optimization. But I would just try all FastCode variants - some can be very verbose, but "may" be better. What I would do in your case, is trying to not move any data at all. Isn't it possible that you pre-allocate a set of buffers, then just consume them in a circular way, passing them from the acquisition to the processing methods as pointers, with no copy? The fastest move() is ... when there is no move... 🙂

I will definitely do that before using it. So far I have just had a look.

Found them, thanks. Just in case anybody else wants to look at them: * for 32 bit: https://github.com/synopse/mORMot2/blob/master/src/core/mormot.core.base.asmx86.inc * for 64 bit: https://github.com/synopse/mORMot2/blob/master/src/core/mormot.core.base.asmx64.inc

I think Arnaud's synopse library has a bunch of more optimised mem copy routines

Maybe this is obvious but I'll just say: the google Cache feature is quite useful on those days when the docwiki goes offline. Google moved that cache feature (in google chrome on desktop, at least). Now it's hidden under the triple-dot menu at the right edge of each normal search result line, and then you have to click the Cache button bottom-right. Definitely better than waiting for docwiki to come back online.

I learned alot from Mike questions and answers. Here's my stab at it. program interSector; {$APPTYPE CONSOLE} {$R *.res} {$o+} uses System.SysUtils, System.Diagnostics, Classes; type // TsetOPs = (EditStr, ButtonStr, CheckStr, FormStr, FrameStr, ListBoxStr, PageControlStr, TabControlStr, RadioBtnStr, ComboBoxStr); TdbKey = (dateID, sqlID, CashID, EditID, ButtonID, CheckID, FormID, FrameID, ListBoxID, PageControlID, TabControlID, RadioBtnID, ComboBoxID); // : integer; TsetKeys = set of TdbKey; const cLoop = 100000000; cSet: TsetKeys = [dateID, CheckID, FrameID, ComboBoxID]; var vSW: TStopwatch; vBool: boolean; procedure IsIntersected(const aID: integer; var aB: boolean); inline var Intersected: TsetKeys; Op: TdbKey; begin Intersected := [CheckID, FrameID, ButtonID] * cSet; aB := aB or (Intersected <> []); //for OPs in Intersected do to build relational DB end; begin vBool := false; vSW := TStopwatch.StartNew; var I: CppULongInt := 0; while I < cLoop do begin Inc(I); IsIntersected(I, vBool); end; Writeln(Format('IsIntersect = %5s', [vSW.ElapsedMilliseconds.ToString])); vBool := not vBool; readln; end. interSector.dpr.44: IsInterSected(I,VBool); 000000000052B51F 89C1 mov ecx,eax 000000000052B521 85C9 test ecx,ecx 000000000052B523 7D05 jnl interSector + $6A 000000000052B525 E8A611EEFF call @BoundErr 000000000052B52A 480FB70D1E010000 movzx rcx,word ptr [rel $0000011e] 000000000052B532 66230D035B0200 and cx,[rel $00025b03] 000000000052B539 803D5831030000 cmp byte ptr [rel $00033158],$00 000000000052B540 750D jnz interSector + $8F 000000000052B542 663B0D09010000 cmp cx,[rel $00000109] 000000000052B549 7504 jnz interSector + $8F 000000000052B54B 33C9 xor ecx,ecx 000000000052B54D EB02 jmp interSector + $91 000000000052B54F B101 mov cl,$01 000000000052B551 880D41310300 mov [rel $00033141],cl interSector.dpr.41: while I < cLoop do 000000000052B557 81F800E1F505 cmp eax,$05f5e100 000000000052B55D 72B6 jb interSector + $55 000000000052B55F 90 nop

This is better handled using a waitable mutex or other synchronization object. The thread can wait on the object when it has nothing else to do, and another thread can signal the object to wake up the waiting thread.

The point that others already have expressed is that despite being interested in a topic as performance improvement so low level (as in instruction-level instead of algorithmic level) you seem to lack some important knowledge to do so such as assembly - it does not require as much as it does to write assembly code but to understand it in order to be able to look at the code in the debugger and see that some comparisons are apples and bananas. I did not even read through your code but simply placed a breakpoint into your IsIN function and noticed that it contained a function call to System.SetElem (that even was the first time I have ever seen that function being called so a TIL for me). Why was that the case? Because you are not using consts here but variables. Had you simply made consts for all those IDs the code would have almost as fast as the IsOR which does not suffer to extra function calls but from memory reads (not noticeable in the benchmark because its all in L1 cache already). On my CPU InOR is still a little faster than IsIN which is due to the fact how the compiler builds the in - you can see that for yourself in the disassembly and then look at instruction timings, read up on macro-operation fusion and data dependency For reference, this is the assembly for the two functions when using consts Project1.dpr.40: Result := aID in [xControlsRec.ButtonID, xControlsRec.FormID, xControlsRec.ListBoxID, xControlsRec.TabControlID, xControlsRec.ComboBoxID]; 004CEE7C 83E802 sub eax,$02 004CEE7F 7417 jz $004cee98 004CEE81 83E802 sub eax,$02 004CEE84 7412 jz $004cee98 004CEE86 83E802 sub eax,$02 004CEE89 740D jz $004cee98 004CEE8B 83E802 sub eax,$02 004CEE8E 7408 jz $004cee98 004CEE90 83E802 sub eax,$02 004CEE93 7403 jz $004cee98 004CEE95 33C0 xor eax,eax 004CEE97 C3 ret 004CEE98 B001 mov al,$01 Project1.dpr.41: end; 004CEE9A C3 ret 004CEE9B 90 nop Project1.dpr.45: Result := (aID = xControlsRec.ButtonID) or (aID = xControlsRec.FormID) or (aID = xControlsRec.ListBoxID) or (aID = xControlsRec.TabControlID) or (aID = xControlsRec.ComboBoxID); 004CEE9C 83F802 cmp eax,$02 004CEE9F 7417 jz $004ceeb8 004CEEA1 83F804 cmp eax,$04 004CEEA4 7412 jz $004ceeb8 004CEEA6 83F806 cmp eax,$06 004CEEA9 740D jz $004ceeb8 004CEEAB 83F808 cmp eax,$08 004CEEAE 7408 jz $004ceeb8 004CEEB0 83F80A cmp eax,$0a 004CEEB3 7403 jz $004ceeb8 004CEEB5 33C0 xor eax,eax 004CEEB7 C3 ret 004CEEB8 B001 mov al,$01 Project1.dpr.46: end; 004CEEBA C3 ret Depending on the number of IDs you have it might be worth using power of two and bitmasks or an enum directly because that would only require one cmp/test making the function twice as fast and perfect for inlining which would then also eliminate the function call overhead at all.

for sure not just because of the numbers

John weeps 😢

Thought for fun let's quickly check the status of 11.1 I really wonder how the dare to publish the product like this. Open example project Notifications (C:\Users\Public\Documents\Embarcadero\Studio\22.0\Samples\CPP\VCL\Windows 10 Notifications\Notifications.cbproj). Run, fine. Open Notifications.cpp. Lot's of 'errors' showns (while it runs fine), like 'vcl.h' file not found, unknown type name 'TComponent', etc etc. Trying code completions with MyNotification-> shows no class members at all. Am I missing something, or is this just the state it is in and C++ devs are expected to be impressed by this and try the product further? Nope...