Leaderboard

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

for sure not just because of the numbers

I have a few functions where I check if 'data' is 'a control', and in some cases I use MatchStr where I have string info, and IN where I have integer ID: function IsControlGroupA(const aControl: string): boolean; Result := MatchStr(aControl, ['Edit', 'Check', 'ComboBox', 'RadioBtn', 'ListBox']); end; function IsControlGroupX(aControl: integer): boolean; Result := aControl in [xConttrols.EditID, xConttrols.CheckID, xConttrols.ComboBoxID, xConttrols.RadioBtnID, xConttrols.ListBoxID]; end; Replacing MatchStr with OR is of course much faster - because we know MatchStr is quite inefficient compared to simple = comparison, so this is much faster: function IsControlGroupA(const aControl: string): boolean; Result := (aControl = 'Edit') or (aControl = 'Check') or (aControl = 'ComboBox') or (aControl = 'RadioBtn') or (aControl = 'ListBox'); end; Then I looked at IN and it looks like simple check of integers, which is fast anyway. So, I benchmarked if it's worth replacing it also with OR: function IsControlGroupX(aControl: integer): boolean; Result := (aControl = xConttrols.EditID) or (aControl = xConttrols.CheckID) or (aControl = xConttrols.ComboBoxID) or (aControl = xConttrols.RadioBtnID) or (aControl = xConttrols.ListBoxID); end; Then I remember reading Marco's response on Case vs If Else about a single comparison and jump: https://twitter.com/marcocantu/status/1501844578898530308?cxt=HHwWiMC-kf_rz9cpAAAA so I put Case into benchmarking and seems like Case is not suitable for my data, since I don't use a large number of ordinals, like Marco explained when Case is faster, and I don't use If Else, so probably not good case anyway, but I put it in so I know how it go against OR. In test benchmark, the OR is a winner, and Case is a bit slower especially in 64bit - which I'm slowly moving into anyway: I benchmarked with my current D 10.2.3 and D 11.1 running in VM: As Marco said, perhaps if I had a large number of checks and if I compared it to If Else, it could win. The real-life difference in one data sample, the most used check for a group is 6x faster using OR vs IN: using IN: using OR: So, definitely quite useful improvement! 1 fact about Case: as we know you can't use Case on non-constant expressions, so using Case for my functions would require a good amount of code change. If it proved to be significantly faster then OR, I would make the change, but it's not. As usual I'm just looking for comment on my observations, perhaps suggestion on something I don't see or didn't take into consideration. And the benchmark code - with the usual limitation of simple repeated calls: program Project1; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.Diagnostics; type TControlsRec = record EditID, ButtonID, CheckID, FormID, FrameID, ListBoxID, PageControlID, TabControlID, RadioBtnID, ComboBoxID: integer; EditStr, ButtonStr, CheckStr, FormStr, FrameStr, ListBoxStr, PageControlStr, TabControlStr, RadioBtnStr, ComboBoxStr: string; end; var xControlsRec: TControlsRec; procedure AssignControlsRec; begin xControlsRec.EditID := 1; xControlsRec.EditStr := 'Edit'; xControlsRec.ButtonID := 2; xControlsRec.ButtonStr := 'Button'; xControlsRec.CheckID := 3; xControlsRec.CheckStr := 'Check'; xControlsRec.FormID := 4; xControlsRec.FormStr := 'Form'; xControlsRec.FrameID := 5; xControlsRec.FrameStr := 'Frame'; xControlsRec.ListBoxID := 6; xControlsRec.ListBoxStr := 'ListBox'; xControlsRec.PageControlID := 7; xControlsRec.PageControlStr := 'PageControl'; xControlsRec.TabControlID := 8; xControlsRec.TabControlStr := 'TabControl'; xControlsRec.RadioBtnID := 9; xControlsRec.RadioBtnStr := 'RadioBtn'; xControlsRec.ComboBoxID := 10; xControlsRec.ComboBoxStr := 'ComboBox'; end; function IsIN(aID: integer): boolean; begin Result := aID in [xControlsRec.ButtonID, xControlsRec.FormID, xControlsRec.ListBoxID, xControlsRec.TabControlID, xControlsRec.ComboBoxID]; end; function IsOR(aID: integer): boolean; begin Result := (aID = xControlsRec.ButtonID) or (aID = xControlsRec.FormID) or (aID = xControlsRec.ListBoxID) or (aID = xControlsRec.TabControlID) or (aID = xControlsRec.ComboBoxID); end; function IsCase(aID: integer): boolean; begin case aID of 2,4,6,8,10: Result := True; else Result := false; end; end; function IsCase2(aID: integer): boolean; begin case aID of 2: Result := True; 4: Result := True; 6: Result := True; 8: Result := True; 10: Result := True; else Result := false; end; end; const cLoop = 100000000; // Values/ControlIDs to search for // 3 values are in the group, 2 are not - similar ratio as in real data cSearch: array[1..5] of integer = (2,4,5,8,11); var vSW: TStopwatch; vBool:boolean; i: integer; begin AssignControlsRec; // IsIN vSW := TStopwatch.StartNew; for i := 1 to cLoop do begin vBool := IsIN(cSearch[1]); vBool := IsIN(cSearch[2]); vBool := IsIN(cSearch[3]); vBool := IsIN(cSearch[4]); vBool := IsIN(cSearch[5]); end; vSW.Stop; Writeln(Format('IsIN = %5s', [vSW.ElapsedMilliseconds.ToString])); // IsOR vSW := TStopwatch.StartNew; for i := 1 to cLoop do begin vBool := IsOR(cSearch[1]); vBool := IsOR(cSearch[2]); vBool := IsOR(cSearch[3]); vBool := IsOR(cSearch[4]); vBool := IsOR(cSearch[5]); end; vSW.Stop; Writeln(Format('IsOR = %5s', [vSW.ElapsedMilliseconds.ToString])); // IsCase vSW := TStopwatch.StartNew; for i := 1 to cLoop do begin vBool := IsCase(cSearch[1]); vBool := IsCase(cSearch[2]); vBool := IsCase(cSearch[3]); vBool := IsCase(cSearch[4]); vBool := IsCase(cSearch[5]); end; vSW.Stop; Writeln(Format('IsCase = %5s', [vSW.ElapsedMilliseconds.ToString])); // IsCase2 vSW := TStopwatch.StartNew; for i := 1 to cLoop do begin vBool := IsCase2(cSearch[1]); vBool := IsCase2(cSearch[2]); vBool := IsCase2(cSearch[3]); vBool := IsCase2(cSearch[4]); vBool := IsCase2(cSearch[5]); end; vSW.Stop; Writeln(Format('IsCase2 = %5s', [vSW.ElapsedMilliseconds.ToString])); readln; end.

Done: https://quality.embarcadero.com/browse/RSP-37770

I don't know much about the US legal system, other than that it is weird by german standards and have no actual case I could point to. But in my opinion a known safety problem like the one this discussion is about would be a quality issue. Of course if the client decides to use such an unsafe installation folder and the possible risk is spelled out in the installation guide then it is his problem. As far as I'm aware (and i'm definitely not a lawyer) in Germany software is treated like other products (hardware) now as far as consumer protection legislation and liability is concerned, so damage caused by faulty software could be reason for a (private) lawsuite. In this particular case it would probably boil down to how much knowlege of the risk involved can be reasonably expected of the user installing the software...

If it helps: when you add images they are listed below the post as Uploaded images and you can delete them by clicking on delete icon, if you can't delete them within the post:

Neater and equally fast ... type Conts = (edit, button, check, form, frame, listbox, pgctrl, tabctrl, radiobtn, combobox); Ctest = set of Conts; const Strs : array[Conts] of string = ( 'Edit', 'Button', 'Check', 'Form', 'Frame', 'ListBox', 'PageControl', 'TabControl', 'RadioBtn', 'ComboBox' ); function IsIN(aID: Conts): boolean ; // inline; begin const test : Ctest = [button, form, listbox, tabctrl, combobox]; IsIn := aId in test; end;

As Stefan said ... without const ... procedure AssignControlsRec; begin xControlsRec.EditID := 1; xControlsRec.EditStr := 'Edit' ; xControlsRec.ButtonID := 2; xControlsRec.ButtonStr := 'Button' ; xControlsRec.CheckID := 4; xControlsRec.CheckStr := 'Check' ; xControlsRec.FormID := 8; xControlsRec.FormStr := 'Form' ; xControlsRec.FrameID := 16; xControlsRec.FrameStr := 'Frame' ; xControlsRec.ListBoxID := 32; xControlsRec.ListBoxStr := 'ListBox' ; xControlsRec.PageControlID := 64; xControlsRec.PageControlStr := 'PageControl'; xControlsRec.TabControlID := 128; xControlsRec.TabControlStr := 'TabControl' ; xControlsRec.RadioBtnID := 256; xControlsRec.RadioBtnStr := 'RadioBtn' ; xControlsRec.ComboBoxID := 512; xControlsRec.ComboBoxStr := 'ComboBox' ; end; function IsIN(aID: integer): boolean ; // inline; begin const test = xControlsRec.ButtonID + xControlsRec.FormID + xControlsRec.ListBoxID + xControlsRec.TabControlID + xControlsRec.ComboBoxID; IsIn := (test and aID) <> 0; end;

Problem is that many of these type of errors, expose only in larger projects.

Same situation with the latest Delphi 11.1 Name der fehlerhaften Anwendung: bds.exe, Version: 28.0.44500.8973, Zeitstempel: 0x6227d05c Name des fehlerhaften Moduls: clr.dll, Version: 4.7.3910.0, Zeitstempel: 0x61b3f594 Ausnahmecode: 0xc00000fd Fehleroffset: 0x004559ad ID des fehlerhaften Prozesses: 0x57c Startzeit der fehlerhaften Anwendung: 0x01d83e9a646f0d6d Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\bds.exe Pfad des fehlerhaften Moduls: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll For what functionality does Delphi use the .NET framework? Anything that I can switch off?

What proportion of the overall time your program takes for the task, is the operation you are trying to optimise in this thread?

I don't think I've ever seen a procedure of a class free the instance of the class it's being called from. Everything in me is screaming DON'T DO IT! This is very bad practice. The object code may still be in memory after the call to Free but it's no longer dedicated to that object and if, per chance, some other operation suddenly uses that available memory, you've got an access violation. And to make an example that shows the problem of the dangling pointer @Attila Kovacspoint out: procedure TForm1.Button1Click(Sender: TObject); begin var DoSomething: TDoSomething := TDoSomething.create; DoSomething.DoSomething; if Assigned(DoSomething) then begin ShowMessage('DoSomething Freed but dangling reference still exists'); DoSomething.DoSomething; // <--- ERROR! end; end; It's better to free the memory outside of the class itself in a try-finally block: procedure TDoSomething.DoSomething; begin ShowMessage('Doing something'); end; procedure TForm1.Button2Click(Sender: TObject); begin var DoSomething: TDoSomething; DoSomething := TDoSomething.create; try DoSomething.DoSomething; finally DoSomething.Free; end; end; This makes it obvious from the calling procedure (the button click event) that the object is freed which lessens the likelihood of using it again because it's right there in the procedure instead of hidden in the class itself.

I use & maintain a fork of TNativeXml, with permission from nils, in the ZaphodsMap project which is open source on sourceforge, here: https://sourceforge.net/p/zaphodsmap I have not corresponded with Nils in more than 10 years. Good to know he is still posting on LinkedIn. FWIW, I still prefer to use TNativeXML when I need to iterate through nodes of XML.

@Stefan Glienke I got a little 'nudge' that my reply above was rude and seems inconsiderate to your help in the past. I hope you didn't read it that way. I took your comment as if my benchmark was waste of time, but re-reading it, I see what you meant. Anyway, I think I was always appreciative to your help and expressed it in past topics. Don't feel like you need to help me in every topic, I have no problem getting no comments on my benchmarks, I take it as "nothing big is wrong with it" or "it's so wrong, it would take me too long to explain", I welcome both options, because they mean either I did something right or I'm slowly getting there. The 64bit projects will go through a lot of benchmarks, so I will probably post more observations like this one, so be on the lookout for something that peeks your interest, I will not be offended if you skip the rest. Also, come on, you can't say that Moe, Larry and Curly's reprisal of 'First!' comment wasn't worth at least a little chuckle at my expense... I know I did, he he.

You will only consider graduates with computing degrees? Seems like that would rule out a lot of good candidates.

I'm a relatively new MVP and have been reading this thread without saying much (partly because I've been away from the computer and partly because I'm new and just listening). The title, at least in my case, was awarded in recognition for what I already do--support the Delphi community. I have been the coordinator for the Oregon Delphi User Group for many years and have been keeping it active. I was also blogging once in a while and was in the middle of writing a book about Delphi. There aren't many hard-and-fast requirements, just keep doing what I'm already doing but maybe a little more frequently; I'm also encouraged to help with beta testing and support forums such as this which I do as I'm able. Yes, we're supposed to be cheerleaders, and I'm happy to do--that but I don't do it blindly and I don't consider myself a paid shrill. I know there are problems with Delphi--I've encountered access violations, refactoring doesn't always work, I miss the Parnassus plugins, etc. There are problems in virtually every piece of software under the sun and if you visit forums for other products, even Microsoft tools, you'll find complaints and frustrations aired there as well (I've read horror stories about trying to develop cross-platform .NET apps with Xamarin; and did you ever write a major app in Visual BASIC then want to upgrade to the latest version? Good luck!). Perhaps there are an inordinate number of major flaws with Delphi but I still seem to be productive--and positive. Maybe it's because I don't do much with high DPI yet or haven't encountered major debugger flaws or some of the other things mentioned as deal-breakers for people--I don't have good answers for them. I do find discussing work-arounds, reporting bugs, and voting for the issues important to me, and yes, talking positively about the features of Delphi or products from Idera and Embarcadero I find really cool, to be much less stressful. I don't profess to know what goes on behind the scenes of Embarcadero but I've worked for enough companies to know corporate decisions often are the cause for features released too early, yet policy heavily restricts what can be said--and that's often very, very little. So I agree that we need to keep discussing the issues and keep reporting/voting for issues on Quality Portal but I hope my humble perspective is helpful to someone. Oh, and for the record, I have a paid Enterprise subscription.

you know, kinds of reminds me of my toilet, which i won't fix as long as i can just wiggle the handle a bit.. so, this works too, until it's fixed by a proper plumber.. unit Unit1; interface uses System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants, FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs, FMX.TextLayout.GPU; type TForm1 = class(TForm) procedure FormCreate(Sender: TObject); procedure FormClose(Sender: TObject; var Action: TCloseAction); private { Private declarations } public { Public declarations } end; var Form1: TForm1; implementation {$R *.fmx} procedure WiggleHandle; begin {$IF RTLVersion111} TGPUObjectsPool.Instance.Free; {$ENDIF} end; procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction); begin WiggleHandle; end; procedure TForm1.FormCreate(Sender: TObject); begin ReportMemoryLeaksOnShutdown:=true; end; end.

Yeah, they could at least have made Fishfacts, amirite?!

I'm so excited about this feature

No, this isn't business as usual. The broken docwiki is not because they are improving it. I know that they are working on a new system, but the old one broke on its own accord. At least that's what I understand from a PM from Marco.

Maybe you shouldn't have let that guy with the strange English accent from "Microsoft Support" help you with you "PC problem" Speaking of sleeping right at night; This thread was actually the topic on my dreams (yes, it was a nightmare) last night: I watched in horror as all my systems were being encrypted before my eyes. Somehow the hacker had so much control over my system that it kept on running even after I pulled the plug. Completely unrelated , but the first thing I did this morning was to run a compete scan on my system.

LOL!! Don't worry I have precedence ... I founded DHS when I was still in high school,Turbo Pascal and Turbo C++ ruled the world ( a long time ago , in a galaxy far away... ) ...

Slightly OT: dhsPinger has an ominous ring to it. Pinging the DHS sounds like something you should not do lightheartedly.

for me too... Some months ago I've updated to 11.0 hoping in a better life but crashes are exactly same of 10.4.2. In the next days, maybe tomorrow, I'll give a chance to 11.1. I hope it won't be worse than it is now. I am now used to restarting the IDE at least once every 10/15 minutes.