Re: Multithreading the IDE?

From: Captain Jake (jake[nospam)
Date: 02/24/05 

Date: Wed, 23 Feb 2005 21:18:25 -0600

Danny Thorpe <dthorpe@bozofilter.borland.com> wrote in message
<421d4282$1@newsgroups.borland.com>
> The Together modeling and source analysis
> code, for example, is not multithreaded and has a "must see all source
> code" design assumption which is not a best match for Delphi source or
> for small footprint high performance in general. That design would
> have the same performance challenges in native Win32 code. That code
> will get a lot of attention for the next Delphi release - and it will
> remain managed code.

I suppose this is already obvious, but just in case it is not, it would be
nice if Borland themselves made it easier to opt out of blocks of
functionality for which we do not want to the the performance hit. I found
D2005 virtually unusable right out of the box, but once I used JED's Delphi
configuration manager to remove Together, it made a huge difference in
D2005's usability. (It would have been nice if we did bit have to do this in
the first place.)

> I am aware of your interest in having an RTL memory manager
> specifically built for performance in multithreaded applications. I'm
> evaluating several options to address that request, but it is not a
> simple matter. Every performance gain has a cost. Most memory
> managers custom built for multithreaded performance have a hidden cost
> of consuming significantly more memory than the more efficient single
> threaded heap manager. If your application already has a large working
> set in memory, slamming it with a 10 to 100x increase in working set
> will do far more damage to application performance (paging) than the
> boost provided by the multithreaded heap.
>
> I will not penalize every Delphi application in order to gain
> performance for a few Delphi apps. Period. There is a middle ground:
> If your app design requires heavy memory allocation by multiple
> threads, use a multithreaded memory manager.

Indeed, it seems that this is the only situation in which third-party memory
managers significantly increase performance. But it would be nice if the VCL
had a multithreaded version that could be used in multithreaded apps, or if
Borland bundled Delphi with a few memory managers from which to choose.

>
> I look forward to seeing the test scenarios and results of the FastCode
> memory manager challenge over the coming months.

I'm very glad that Borland is keeping an eye on the FastCode project. It is a
perfect example of how the Delphi community is one of the greatest assets
Delphi has. 

-- 
***Free Your Mind***
Posted with JSNewsreader-BETA 0.9.4.431

Relevant Pages

  • Re: GetTotalMemory, GlobalMemoryStatus
    ... Windows CE Product Manager ... > OK, sorry, when I said "no other apps" I meant no apps of mine (thought ... > "taking in account memory used by the system" bit covered that)... ... In other words if I have PInvoke calls that allocate memory ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Lets think who will like to say delphi is dying?
    ... Is it a 2GB or a 4GB limit on memory for 32 bits? ... Either way many apps don't need that much memory. ... the cash benefit of 64 bit memory for most desktop application developers? ... of new Delphi customers, or create significant demand for more Delphi ...
    (borland.public.delphi.non-technical)
  • Re: Question about FastMM
    ... > memory manager, some apps might break. ... > probably Delphi 2006 should both a new, ...
    (borland.public.delphi.non-technical)
  • Re: Executing query eats up memory ?
    ... You can use Task Manager on the server to view the amount of memory the ... VB apps take during execution. ...
    (microsoft.public.sqlserver.programming)
  • Re: Memory question: largest contiguos size
    ... Actually, those apps were not written in Delphi, but C++. ... constantly monitor the largest contiguous block of memory available in those ...
    (borland.public.delphi.language.basm)