Board index » delphi » Re: Multithreading the IDE?

Re: Multithreading the IDE?


2005-02-24 11:18:25 AM
delphi42
Danny Thorpe <XXXX@XXXXX.COM>writes
<421d4282$XXXX@XXXXX.COM>
Quote
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.)
Quote
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.
Quote

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
 
 

Re: Multithreading the IDE?

Captain Jake writes:
Quote
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.)
Thanks for the plug Jake... The amazing thing is, the initial purpose
wasn't to help with performance issues of Delphi. Version 2 is
currently being beta tested and when released, you will get an even
bigger insight in why I created it - and use it extensively.
www.alphalink.com.au/~jed/dcm.htm
I'm going to update the website with some upcoming features and
screenshots as my blog post about it has move down the list a little.
--
QC Client: www.alphalink.com.au/~jed/QC/
Blog: jedqc.blogspot.com/
Configure Delphi the way you want it to be:
www.alphalink.com.au/~jed/dcm.htm
Checkout my code central submissions for D2005
cc.borland.com/ccweb.exe/author
 

Re: Multithreading the IDE?

JED <XXXX@XXXXX.COM>writes
<XXXX@XXXXX.COM>
Quote
Thanks for the plug Jake... The amazing thing is, the initial purpose
wasn't to help with performance issues of Delphi. Version 2 is
currently being beta tested and when released, you will get an even
bigger insight in why I created it - and use it extensively.
I have a sneaking suspicion that it has to do with maintaining different
packages and groups of controls for different development projects. If so, I
look forward to version 2.0.
I had an idea a few years ago that I thought was really good, for a utility
that would find and zip up all the components needed for a particular
development project, so that you could easily install those components in
another copy of Delphi. It would be really useful for making sure all members
of a team were up to date in terms of installed components needed for any
given project. You'd just use this utility to install them from a single file
off the network. The utility would use RTTI and the Delphi registry entries
to find and compress all the components. But when I mentioned it here on
non-tech the reaction was pre{*word*109}ly negative, so I didn't do anything
with the idea.
--
***Free Your Mind***
Posted with JSNewsreader-BETA 0.9.4.431
 

Re: Multithreading the IDE?

Captain Jake writes:
Quote
I had an idea a few years ago that I thought was really good, for a
utility that would find and zip up all the components needed for a
particular development project, so that you could easily install
those components in another copy of Delphi. It would be really useful
for making sure all members of a team were up to date in terms of
installed components needed for any given project.
Hey, be quiet... You are talking about a future product. Something
along the lines of "DCM Team". Change Requests for such a beast are
already in my StarTeam repository <g>
--
QC Client: www.alphalink.com.au/~jed/QC/
Blog: jedqc.blogspot.com/
Configure Delphi the way you want it to be:
www.alphalink.com.au/~jed/dcm.htm
Checkout my code central submissions for D2005
cc.borland.com/ccweb.exe/author
 

Re: Multithreading the IDE?

JED writes:
Quote
Hey, be quiet... You are talking about a future product. Something
along the lines of "DCM Team". Change Requests for such a beast are
already in my StarTeam repository <g>
Oh, and I can not take all the credit for the idea as Kristofer Skaug has
mentioned it to me.
--
QC Client: www.alphalink.com.au/~jed/QC/
Blog: jedqc.blogspot.com/
Configure Delphi the way you want it to be:
www.alphalink.com.au/~jed/dcm.htm
Checkout my code central submissions for D2005
cc.borland.com/ccweb.exe/author
 

Re: Multithreading the IDE?

Quote
The Delphi IDE has been multithreaded since Delphi 3, and has used the
Delphi RTL memory manager the whole time. Please stop fingering the
memory manager as the defacto scapegoat for every performance issue.
I'm not scapegoating. I was merely making a guess at a possible
problem. If my guess was wrong, then fine.
Quote
I am aware of your interest in having an RTL memory manager
specifically built for performance in multithreaded applications. I'm
How are you aware of my interest? Have I stated such before?
Quote
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.
Well, I have always thought that a selectable memory manager was the best
solution, which we have today. However, I would just like to see a better
memory manager included out-of-the-box. Which is what I initially
suggested in your licensing the NexusMM.
--
Jason Southwell
www.arcanatech.com
Delphi & IntraWeb Components
Consulting and Contracting
Incident Based Support
 

Re: Multithreading the IDE?

Danny Thorpe writes:
Quote
The performance issues that people have reported in Delphi 2005 are
almost exclusively related to source code data mining performed
continuously in the background, used by the flotilla of new
productivity features added in Delphi 2005. As some have figured out
on their own, a large portion of that is tied to the Together modeling
and source analysis tools. Other pinch points have been identified in
some of the new CodeInsight features.
[Snip]
Quote
I look forward to seeing the test scenarios and results of the
FastCode memory manager challenge over the coming months.

-Danny
Thank you for responding to this. It means a lot to people (at least
me) to hear this kind of information from someone who works on Delphi.
I am glad that Borland recognizes this as a problem and is looking into
it.
Thanks
Joe Bain
 

Re: Multithreading the IDE?

JED <XXXX@XXXXX.COM>writes
<XXXX@XXXXX.COM>
Quote
Hey, be quiet... You are talking about a future product.
Ah. That is good to hear!
--
***Free Your Mind***
Posted with JSNewsreader-BETA 0.9.4.431
 

Re: Multithreading the IDE?

JED <XXXX@XXXXX.COM>writes
<XXXX@XXXXX.COM>
Quote
Oh, and I can not take all the credit for the idea as Kristofer Skaug has
mentioned it to me.
Aha. Plagiarist. <g>
--
***Free Your Mind***
Posted with JSNewsreader-BETA 0.9.4.431
 

Re: Multithreading the IDE?

Captain Jake writes:
Quote
JED <XXXX@XXXXX.COM>writes
<XXXX@XXXXX.COM>
>Oh, and I can not take all the credit for the idea as Kristofer Skaug
>has mentioned it to me.

Aha. Plagiarist. <g>
hmm. after he saw DCM initally.
--
QC Client: www.alphalink.com.au/~jed/QC/
Blog: jedqc.blogspot.com/
Configure Delphi the way you want it to be:
www.alphalink.com.au/~jed/dcm.htm
Checkout my code central submissions for D2005
cc.borland.com/ccweb.exe/author
 

Re: Multithreading the IDE?

"JED" <XXXX@XXXXX.COM>writes
Quote
Captain Jake writes:
>Aha. Plagiarist. <g>

hmm. after he saw DCM initally.
Aha. Self-plagiarist. you will go blind. <g>
 

Re: Multithreading the IDE?

Quote
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.)
This is another area of improvements into which we're looking.
--
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corporation.
blogs.borland.com/abauer
 

Re: Multithreading the IDE?

Quote
How are you aware of my interest? Have I stated such before?
I beleive Danny was using a more collective "your" in this case. English is
so abiguous sometimes...
Quote
>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.

Well, I have always thought that a selectable memory manager was the best
solution, which we have today. However, I would just like to see a better
memory manager included out-of-the-box. Which is what I initially
suggested in your licensing the NexusMM.
We're investigating a lot of options at this point. Details of which are
far from being finalized and/or announced. However, you need to realize
that the existing Delphi MM, has enjoyed over 8 years of life in the Delphi
product. There have been no changes to the MM in many releases, so it is
quite "tried and true." While not bleeding edge, it works sufficiently for
the vast majority of Delphi applications, including the Delphi IDE itself.
--
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corporation.
blogs.borland.com/abauer
 

Re: Multithreading the IDE?

Quote
Thank you for responding to this. It means a lot to people (at least
me) to hear this kind of information from someone who works on Delphi.
I am glad that Borland recognizes this as a problem and is looking into
it.
Let's not blow this out of proportion. Yes we *do* recognize that there are
a certain class of applications that will benefit from a better performing
multi-threaded MM, but quite frankly, those applications affect only a small
a portion of the overall Delphi customer base. Providing an alternative for
those classes of applications is what we're looking into. Danny and I
largely object to the blanket implications that the Delphi MM is broken for
all cases. It is merely sub-optimal for a certain class of applications.
--
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corporation.
blogs.borland.com/abauer
 

Re: Multithreading the IDE?

Allen Bauer writes:
Quote
>Thank you for responding to this. It means a lot to people (at least
>me) to hear this kind of information from someone who works on
>Delphi. I am glad that Borland recognizes this as a problem and is
>looking into it.

Let's not blow this out of proportion. Yes we do recognize that
there are a certain class of applications that will benefit from a
better performing multi-threaded MM, but quite frankly, those
applications affect only a small a portion of the overall Delphi
customer base. Providing an alternative for those classes of
applications is what we're looking into. Danny and I largely object
to the blanket implications that the Delphi MM is broken for all
cases. It is merely sub-optimal for a certain class of applications.
Sorry I was refering to the speed of the IDE not the MM.
As Danny stated:
The Delphi Win32 RTL memory manager is not a factor, since both of
those subsystems are .NET managed code.
I can use any MM I want. For normal GUI program I do use the RTL MM,
but for applications servers I use other MMs.