Anders Melander

Remember back in the day when a new release made you go Wooo Hooo ? This release? Meh

You could probably have used the MSSQL Server Profiler to determine what the server is doing when you run the query. With regard to transactions, I always use explicit transactions. BeginTransaction; try DoStuff; CommitTransaction; except RollbackTransaction; raise; end;

Um... Unicode, 64 bit, generics, anonymous methods, inlining, record methods....? Thanks. Halfway there 🙂 Unfortunately I don't think it's a realistic goal to beat C++ without rewriting the hotspots in assembler.

Why? I get it that there are people who are stuck on Delphi 7 and refuse to upgrade but do those people really need your library? You can move the assignment of nodeI outside the loop and increment it inside the loop. I doubt that it makes any difference in performance but at least it will not trigger my OCD. I'd be interested in seeing how the performance compares against C++ and C# at this point. Can you post the updated numbers, please?

Yes it should be but I think there might be too much register pressure here for the compiler to generate the code we want. Haven't tried it though. Also we need the pointer anyway after the iteration. Left as an exercise to the reader :-)

With Delphi 10.3 the benchmark is slower when compiled for 64-bit compared to 32-bit. Are you seeing something else? They make a pretty big difference on my system when compiled for 32-bit. I'd say around 20% improvement. I could be wrong because I'm working on my day job at the same time. I just tried using a pointer instead of the list getter inside the loop in ProcessIntersectList and that seems pay off: procedure TClipperBase.ProcessIntersectList; var ... node: PIntersectNode; node2ptr: ^PIntersectNode; ... begin ... for i := 0 to highI do begin node := UnsafeGet(FIntersectList, i); if not EdgesAdjacentInAEL(node) then begin j := i; node2ptr := @FIntersectList.List[j]; repeat inc(node2ptr); until EdgesAdjacentInAEL(node2ptr^); // now swap intersection order FIntersectList.List[i] := node2ptr^; node2ptr^ := node; end; ...

What Stefan wrote 🙂 I had my focus on the exact same three areas and had made almost the same changes. When you look at the profiling of the generated asm it becomes pretty clear what the bottlenecks are - down to the individual statements. In addition to Stefan's modifications I would try to see if it made any noticeable difference to test for (i = 0) last in IntersectListSort because presumably the two other conditions are met more often. It could eliminate one or two branches. I would also consider if quick sort is the best algorithm to use. For example if the list is already "almost sorted" (for example because a sorted list was modified), insertions sort might be a better choice.

I hadn't thought about using TLists.List so I would probably have tried avoiding TList altogether. Maybe TLists.List is good enough and it's certainly an easier fix that replacing TList. A new profile run would answer that. I only spent 5 minutes looking at the profile result yesterday so I can't give much details, but one thing I noticed is that you're iterating a list sequentially in ProcessIntersectList. Since TList is basically just a wrapper around a contiguous array, a sequential iteration can be done by just incrementing a pointer inside the loop thus bypassing the getter altogether. The profile results also hints that some things might be made slightly faster just by moving things around a bit. A better optimizer would have done that for us but alas we have to work with what we got. I will try to find time to look at this more closely this week end.

Something like this? The above was done with a standard TTreeView using ownerdraw (and "a few" hacks). I've attached the source but it's part of a larger framework so it will have to be tweaked a bit in order to work standalone - Minor stuff. If I were to implement this today I would definitely use Virtual TreeView instead; L oad the XML into a DOM (e.g. MSXML/IXMLDocument), populate the treeview and ownerdraw the nodes. amResourceViewXML.pas amResourceViewXML.dfm amTreeView.pas

PDF? Not really the same as "pdb" 🙂 Anyway there are plenty of other Hex editors but I think it's bad form to hijack this announcement thread to discuss that.

I just tried NativeJpg32, and while it has quite a few more dependencies (on the other SimDesign units) than what I would have liked, it worked well on everything I threw at it. With regard to memory usage I tried loading a 16.4 Gb jpeg file (7900x5430 pixels) into a TBitmap32. The TBitmap32 as expected consumed 163 Mb. The peak overhead during load and conversion was 600 Mb. Loading the same image as a BMP into TBitmap32 and then converting it to JPEG caused a peak overhead during conversion of 675 Mb and resulted in a jpg filesize of 11.1 Mb. Of course the two file were no longer identical due to the lossy jpeg encoding. I did not experience any leaks.

Nope. Have you read the section "How to handle source code changes"? O.M.<expletive>G.

This one seems to do just that: https://github.com/taazz/simdesign/blob/87fdcc43f3a71016280cdbfc11de6cf4dd836254/simlib/nativejpg/NativeJpg32.pas Haven't tried it though.

Excellent. Can't wait to give it a spin.

That's what she said Sorry

There are undoubtedly different opinions about this but I would say that you should completely separate design- and compile-time stuff. Build and install your design-time package and never mind where the dcu files for that are located. Just don't have them output to the same folder as the source. I would probably place them (via the package project options) in a sub-folder of the package source but you could just as well delete them once the package is installed because they are only needed to build the package. Reference the source files directly, or via the search path, in your project and have the dcu's output to the project dcu folder. Do not include the dcu output folder in your project search path.

Impressive! I could have used this when I reverse engineered the pdb file format. I have one suggestion based on a quick look though the source: It seems data is read unbuffered and edits are done directly on the source (file/disk/memory). This is fine as it allows one to edit huge binary files without loading them into memory (which surprisingly is what many other hex editors does). One thing I could wish for would be a mode that cached edits in memory and then allowed those edits to be applied/committed to the source on demand. You could probably implement this with a block cache layer on top of your existing data source layer.

Sure, but that's hardly worth USD 600/year. Most of the stuff on that list is just repackaging of their existing features. Pfft!

Fork the repository. Create a branch on your fork. Apply the changes to your branch. Push the changes to your fork. Create a pull request to have your branch merged into the original repository.

Do you have AutoSize=True on the labels?

You can create a run-time package containing synedit (a run-time package is a DLL) and link against that but one way or the other you are going to create a dependency on synedit and compiling it directly into your project is the the option that will give you the least problems.

Not very shocking if you understood what was going on. When you install a component your code will be run as a part of the IDE process. If your component code goes into an endless loop then you will have hung the IDE. Nothing surprising there. So is Delphi. I'm assuming you're a hobbyist because otherwise VS isn't free AFAIK.

No you don't. I understand why you used it but there are always better ways to solve a problem than using [weak]. Contrary to what the documentation states [weak] isn't named named after the type of reference. It's named after the design skills of people who choose to use it to manage references. 🙂

P.S. Tabs are Evil!

Why? What problem are you trying to solve? While I'm definitely a proponent of interfaces at a higher level, at low level they often just obfuscate the code. Apart from that I think your solution has a number of "smells": Why is the TDrawingObject.ObjectType writable? Does the ObjectType really need to change after construction? Why is TDrawingObject.DrawingObjectsList writable? Who owns the list? (might have been covered before. TL;DR) Instead of exposing the whole TObjectList<> class, expose only the relevant parts (Add, Remove, Enumerator). See: Why is TDrawingObjectsList.OwnsObjects part of the API? Isn't the ownership an implementation detail?