Leaderboard

Here's a quick update on the two issues @Allen@Grijjy encountered: The problem with the overlapping segments has been worked around in code by ignoring conflicts caused by the .tls segment. Incidentally, Allen found an old QC report about a similar issue (RSP-12824). Unfortunately, that issue was closed by someone who apparently doesn't understand what the map file segment offset values signify. Regardless, an overlapping .tls segment now only produces a warning message. The filter problem turned out to be a copy/paste problem. Allen had copied his map2pdb parameter list from a post here, and somewhere along the way, two invisible zero-width no-break space characters (#$F0FF) got inserted into the string he pasted. So what looked like '-include:0001' was actually '-include:000'#$F0FF#$F0FF'1'. I've been bitten by that one myself a few times when I've copied code from a browser.

Just use thousands of threads and get results yesterday, simples. No, if you use too many threads then your will get results slower. How do you even think computers work?!!

get results faster

When I run that code in a vanilla VCL Forms Application in a ButtonClick event - nothing happens. Either commenting out the last line or inserting a Sleep(100) before makes the ShowMessage appear. The problem here is that the anon method captures the variable and not the value. Thus setting the value of TerminateProc to nil has influence of what is passed to TThread.Queue. It heavily depends on the timing of whether the Queue call comes first or the setting to nil. Seems not to be a valid solution to avoid the leak.

A HIDDEN GEM IN DELPHI SOURCES (SHELLCONTROLS) Many times I intercept requests on the WEB from Delphi developers for components of the Windows "Shell" (similar to Windows Explorer) that were once present in Delphi (maybe in Delphi XE3), which have "disappeared" from the Delphi components palette. Those components are: - TShellComboBox - TShellListView - TShellTreeView - TShellChangeNotifier The good news is that those components are still there and have also been updated over time, but the packages are missing and are therefore not installed "by default" in the Delphi IDE 🙁 So we have prepared a Repo on Git-Hub containing the packages of these components, to facilitate their installation in the Delphi IDE and therefore their use. The prepared packages are for different versions of Delphi, starting from Delphi XE6 up to Delphi 12 and are available here: https://github.com/EtheaDev/DelphiShellControlsPackages In the same repository there is also a small Demo that shows the components "in action", also reconstructed from a demo present only for C++ and transformed in Delphi Pascal. bye Carlo

XML used to be considered the universal data format. Now is a bit passé with JSON, YAML etc being "in". I got involved in XML parsing, since SVG files are in XML format. XML Delphi support At the surface the XML support in Delphi is very good: You have TXMLDocument/IXMLDocument offering high-level support (Xml.xmldoc) Support for the standard DOM interfaces (Xml.XmlDom) Multiple implementations including (MSXML, OmniXML, OpenXML and more) Ability to plug in your own implementation Multiple platform support. The most common way of accessing XML is through TXMLDocument/IXMLDocument. However there is a big catch: PERFORMANCE. Say you want to use MSXML and you specify 'MSXML' as your DefaultDomVendor. (or you simply include the implementation unit Xml.Win.msxmldom in your uses clause). Your create an XML document and you access the top node: var Doc: IXMLDocument = TXMLDocument.Create(nil); var Node: IXMLNode := Doc.DocumentElement; Node is an IXMLInterface implemented by TXMLNode (TInterfacedObject defined in Xml.XmlDoc). TXMLNode wraps an IDOMNode stored in a private field FDOMNode. IDOMNode is defined in Xml.Xmldom. The IDOMNode is implemented by the used vendor in this case Xml.Win.msxmldom by a class TMSDOMNode TMSDOMNode (also a TInterfacedObject) wraps IXMLDOMNode stored in a private field FMSNode. IXMLDOMNode is defined in Winapi.msxml. As a result when you create any IXMLNode, a TXMLNode is created and this creates a TMSDOMNode which points to an IXMLDOMNode. Any call/property access to IXMLNode translates in a call of IDOMNode which then calls IXMLDOMNode. The created TInterfaced objects also need to be destroyed when you release your XML Node. The same two-level indirection applies to all XML objects (attributes, Children) and cause a huge degradation of performance. Conclusion If you care about speed forget about TXMLDocument. You can access the Vendor implementation or even better in the case of MSXML the Microsoft ActiveX objects directly: uses WinAPI.msxml var XML: IXMLDOMDocument3 := CoDOMDocument60.Create; XML.loadXML(XMLString); var DocNode: IXMLDOMNode := XML.documentElement; In SVG parsing and processing accessing directly the ActiveX objects reduced processing time by more than 50%. Additional tip A common performance pitfall with MSXML is explained in http://www.gerixsoft.com/blog/delphi/msxml. The fastest way to iterate through ChildNodes is via getFirstChild/nextSibling and Attributes via nextNode.

I can't remember which unit it was, and which Delphi release, but there was a constructor similar to this where some graphics or hash table was filled with thousands of lines. After a certain size, the compiler silently cropped the code and linked the exe without any error. Nevertheless, I would rewrite the generator to produce 16 (0-F first byte) array constants, sorted by the MAC address rather than the vendor. Additionally, I would substitute the vendor string with a lookup table to eliminate the redundant entries.

CPU is a finite resource. You will not get more of it, by throwing in more threads. If there are more threads than CPU cores, those threads will compete with each other for CPU time, and switching between threads also costs some CPU time. So after you overload the CPU, more threads you add the slower it will work. Only if threads are doing some I/O bound work, then you can have more such threads than CPU cores and possibly whatever you are doing can finish in less time. In other words if the thread spends most of the time waiting for some slow I/O operation, then such thread will not fully utilize CPU core and other threads can do useful work in the meantime on that core. However, even in I/O bound operations, there are limitations and if those threads are competing for the same resources, then again, the whole process will run slower. Imagine that CPU core is a shovel and threads are workers. In CPU bound work workers need to dig some ground. If you have same amount of shovels as workers than each worker will use the shovel all the time without having to give it up and it will be able to do the digging at full speed. If you have more workers than shovels, then workers will compete for that shovel. And it will not be in a way that some workers will use the shovel all the time and others will do nothing, but each worker will get very short time to use the shovel, maybe only taking one or two loads, and then it will have to give the shovel to the other worker that is waiting. But transferring shovel from one worker to another takes time, and at the end everything will run slower than if you have only one worker per shovel. On the other hand, if the worker also needs to use a pickaxe, then while worker is using the pickaxe, he does not need the shovel, and someone else can use it until the worker is done with the pickaxe. This is example of I/O bound work, where pickaxe is some I/O resource (network, disk...). Again, if you have more workers that compete for the pickaxes, the whole thing will work slower than single worker using that pickaxe. Now, this is simplified example. When it comes to your application running, it is not just your application that uses the CPU cores, but OS and other processes and applications are also using them, so you also need to take those into account. Now finding the right balance for the actual work can be hard and will depend on other parameters, and usually you don't have to optimize that much. But in simple terms, you definitely don't want to have more threads working at the same time than CPU cores, if those threads are doing CPU bound work. Commonly using as much threads as CPU cores or one less, will do - you can experiment with that, but again this is something worth pursuing for most applications. If you are writing something that will run on specific hardware then you can more easily optimize, but if you need to make it work across different ones, then good optimization for one may be a bad optimization for another.

Answer myself. I remember having seen these some time ago, when I have been bitten by this again: delphi - Memory leaks happens in nested anonymous method - Stack Overflow TURBU Tech » Blog Archive » How to leak a class you never defined (turbu-rpg.com) (see Barry Kelly's comment).

993 is the default port for Imap over TLS, so this is probably meant as a feature. (Not that I would have expected this to happen.)

[Some time later] I've now discovered that the IdSSLIOHandlerSocketOpenSSL1 code changes the TIMAP4.port property to 993, even though my server wants 143, so setting TheImap.Port := 143; after setting the IdSSLIOHandlerSocketOpenSSL1 properties, addresses the issue. Not sure if this is an Indy bug or a misunderstanding of how it should work by me. Replying to my own question simply because this will no doubt bite me on the bum in 5 years time when I refactor the code !!!

IBExpert has a tool to compare the metadata of two databases, and generate a update script with the differences.

Importing a module for second, third.. time has no significant performance cost.

No, not al all. Remember a few decades ago, when most personal computers had only one processor? We had multiple threads then, the operating system cycles them for you nicely, even over the several processors if your system has more. If you're running really intensive work in the threads, you may cause slowdowns by having more threads than processors (it's interesting to learn about thread affinity as well), but as soon as you're doing I/O from these threads (and the system handles device calls on your threads) you may get an increase of total performance, because the system can let more threads work while some threads are 'waiting'. There's more to the story when you're using completion ports, or do overlapped IO calls... But only remotely related to your question about threads.

And here is a less simple way running Python code in a thread and keeping the main thread free to handle printing. It also shows how to buffer the output. LessSimpleDemo.zip

Here is a super simple approach. SimpleDemo.zip

If you are interested in performance, http://kluug.net (Ondřej Pokorný) has two excellent libraries; the freeware OmniXML and the commercial OXml. I'm user and customer of OXml On this page: http://kluug.net/oxml.php choose the Performance tab and you will see a thorough comparision between most Delphi XML libraries. OXml shows about 10 times faster than MSXML I purchased both OXml and OExport, and quite happy with them Note: No, I'm not related to Kluug in any possible way, other than customer/user of his librtaries