David Heffernan

I'm sure you are right. It just seems weird that any git program could have performance issues when all they are doing is wrapping git.

Before knowing how to fix it, you need to know what causes the leak. That's where the minimal reproduction comes in.

A complete reproduction is surely needed here. As an aside, can't you use a read lock here?

We can help you but we need you to provide clear information. If you want to continue posting random scraps of information that mean nothing to us (we don't have your code, or a minimal reproduction), the posts in this thread are not actionable. As somebody who has experience debugging memory I can assure you that you are going about it the wrong way. We can for sure help, but it requires you to provide clear information and take a more structured approach. If you don't want to do that, and wish to continue with trial and error, that's fine. But please don't consume bandwidth here by posting scraps of information that means nothing to us. Remember that this is a public forum. Every post you make is broadcast. We don't to spend our time sifting through posts looking for the useful actionable content.

Dude, you've got a memory corruption somewhere, and the behaviour of such bugs is often not repeatable. Change something in one place, and the bug is hidden, only to pop up somewhere else. I suggest that you stop posting here unless you have something concrete to share, and ask for help. Why are you posting you trial and error debugging in a public forum? Do you know what valgrind is?

We are doing just that. These continued postings are just noise for us. Clearly you have a problem but unless you can provide a clear reproducible case then your latest piece of guesswork doesn't warrant an update here. These bugs can be hard to track down. That's why we use tools like valgrind. They track them down instantly.

Hard to see how source tree could be slow to pull when all it is doing is shelling out to git......

Public service announcement: If you don't reply to a comment that is leading nowhere, the thread just ends.

Can't you debug the code on windows. Might be easier there and now possible because the memory model is the same. On Linux you can of course use valgrind.

C# has had this cracked for more than 10 years now. Why can't Delphi get it done?

Again I don't think that's true. Certainly in conversations with folks at Emba they do recognise many issues with their current product on Windows.

Sometimes it takes strength to say no to some customers.

I dispute that. I don't see anything wrong with a business model that concentrates on enhancing and developing their core market. Imagine what could have been achieved on Windows if all the resource that was used on the new platforms had been spent on Win32 and Win64? Remember also that the vast majority of the income is still from the Windows tools.

Sure it's down to a lack of resources. But that's a consequence of expanding to new platforms. Each additional platform comes with a maintenance cost. That cost is paid for out of revenue. The bulk of the revenue comes from customers that are using the legacy platforms. If Emba continue to neglect their core business (Windows development tools) then eventually customers will look elsewhere.

Kinda galling to realise the effort Emba is putting in for 64 bit mobile and Mac desktop platform support (all minority user bases) and at the same time the Windows compilers (overwhelming majority user base) receive no attention at all. What kind of business model is it to take money of your customers and then spend it on developing functionality that is not useful to the majority of your customers?

Stepping through execution in an interactive debugger is fine for some debugging tasks, but it's just one form of debugging. It's hopeless for debugging threading specific issues. It's the wrong tool. Lots more to debugging than interactive debugger step through.

It's not obscure if you realise that Longint and Longword map to the corresponding C++ types long int and unsigned long int whose size is determined by the platform ABI.

I think that post is about accessing a COM object exposed by a .net assembly. But I think that the asker is embedding the .net runtime via its COM interface. So I expect that there is a way to obtain Type and call methods on it, but who wants to scour 32kloc and learn how to use that darn thing. Surely the entire enterprise would be easier by exposing the target code with a .net layer, e.g. a COM wrapper of the target code.

Yes, you are wrong. If you have two threads reading then they are not synchronisation with respect to each other.

Cut it down to a minimal repro. Although it is likely that the answer has been revealed in other comments about the misuse of the lock.

Defect in the code that isn't shown here.

Use classic memory management. obj := TMyObject.Create; try obj.DoSomething; finally obj.Free; end;

They really aren't complex at all to use. Which is my point. You are talking about the implementation details. If you find C# complex then that's on you. Since you declared a few comments back that you didn't really have a sound grasp of C# delegates perhaps you should become knowledgeable on the subject before acting like an expert. Just a thought. Myself, I don't find C# delegates at all complex. It would certainly be pretty convenient if you could use anon methods as event handlers, as you can trivially do in C#. I understand why you can't in Delphi and it's too late to change now. But when you write code in other languages that don't have backwards compatability constraints, it can be irritating when you come back to Delphi.

Er, the complexity is in Delphi with its multiple different procedural types. C# delegates are simple.

Yes to all questions.