String Processing and Collections - improvements needed in native VCL
jeffc
versions of Delphi, here is my biggest request for the core Win32 VCL.
What I really would like to see is the new DevCo hiring the FastCode guys
and let them work full time on this stuff. Not only creating improved RTL
functions, but also creating a expanding the VCL by adding a better String
processing library and a superfast and powerful Collections library
(improved TStringList, etc).
As someone once said, its all about the FrameWork.
But what if DevCo took a stance to put effort into expanding the Win32
VCL. Take for example, all the fast 3rd party String libraries we have:
HyperString, FastStrings, JEDI JCL, etc. Borland should expand the Win32
framework so it has the most powerful string processing and collections
libraries built in. This way its all there and your not having to use
external libraries to do what I call the core 50% of all programming which
is working with collections and strings.
If 50% of most code written is using these 2 things, then shouldn't DevCo,
which is developer focused, look at making the libraries supporting these
programming features the best they can be?
I mean half of this stuff if not more has already been done and most of it
is probably available for Borlands taking with negotiation. Someone then
needs to put it all in a blender and get the best stuff out of them all.
If I have extremely fast optimized and highly flexible functions/classes
for the 50% of all programming I do, then this is going to make my
programs run better and my productivity coding increase.
Today in these 2 spots (Collections and String processing), I believe that
Delphi supports just the bare minimum. The FastCode project is a step in
the right direction, but their focus is on improving the core RTL. In
addition this is happening outside of DevCo and not on a full-time basis.
Shouldn't this type of work be part of DevCo?
--- posted by geoForum on http://delphi.newswhat.com
![Marc Rohloff [TeamB]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Marc Rohloff [TeamB]
> If 50% of most code written is using these 2 things, then shouldn't DevCo,
> which is developer focused, look at making the libraries supporting these
> programming features the best they can be?
I don't think that most people will upgrade for any of these. IMO the
money would be better spent elsewhere.
--
Marc Rohloff [TeamB]
marc rohloff -at- myrealbox -dot- com
jeffc
Java Collections - just look at the variety of choices and power Java
developers have:
http://java.sun.com/j2se/1.5.0/docs/guide/collections/reference.html
Not to mention the additions the Apache project made:
http://jakarta.apache.org/commons/collections/
Now lets look at .NET:
System.Collections.
ArrayList
Hashtable
CollectionBase
Stack
Queue
BitArray
System.Collections.Specialized.
StringCollection
StringDictionary
ListDictionary
HybridDictionary
And lets not even get started how Generics in .NET 2.0 is going to
radically change the way we use collections.
Ruby has some powerful features with its collections as well. Alot of
this is also found in SmallTalks very mature collection classes as well.
Some of its power and simplicity is in it implementation of Enumerable.
http://www.ruby-doc.org/core/classes/Hash.html
http://www.ruby-doc.org/core/classes/Enumerable.html
Even Ray Lischner decided to write his own Collection Classes:
http://www.tempest-sw.com/nutshell/cltn50.html
And Marco Cantu discusses in great length the Delphi Collection classes here:
http://www.mygnet.com/articulos/delphi/283/
As I read thru this article I am more confused then ever and it seems like
you have to know these classes entremely well to use them best. Of course
all this great information that Marcu supplies is barely covered the the
Delphi docs. Again I think this article screams for Delphi to get a more
simplefied, organized, and optimized collections framework, bringing it up
to speed with whats offered in other modern frameworks.
Marco even compares Delphi RTL collections with .NET:
"In the StringListSpeedNet demo you can see that the FCL solutions are
constantly faster than the Delphi RTL solutions."
Of course this was before the FastCode functions were introduced into the
latest version of Delphi. These may now function better due to some
functions like Pos() being Fastcode optimized. Again, these FastCode guys
making Delphi better.
Some other interesting Marco comments:
"Delphi's THashedStringList class, found in the IniFiles unit (as
described earlier) provides extra speed when you need to perform multiple
find operations on a non-changing string list. As the class is used to
implement TMemIniFile, the idea that the data seldom changes fits
properly. But for a generic use, this class falls short. In fact, if
THashedStringList performs great while searching an existing list, it is
so slow to become unusable if the string list changes over time, as the
entire hash table is recalculated every time a string in the list changes."
"Getting back to hash codes it is relevant to mention that in .NET every
object has its own Hash function (available in the base Object class),
which comes very handy when implementing any hashed data structure."
In the same article, he goes on to talk about Strings and the innovations
in .NET. Hmmm, he mentions Strings and Collections in the same article ;)
Another article here explaining the complexity of using TCollection:
http://www.atug.com/andypatterns/collections.htm
These threads here seem to show an intrest in optimizing TStringList:
So you are telling me that not many Delphi developers would be interested
in the Native VCL being brought up to speed with collections in other
modern languages. Especially when a bulk of the programming work we do is
managing data in collections.
I find that hard to believe. Maybe others can comment with their opinions.
Peter Morris [Droopy eyes software]
> and let them work full time on this stuff.
I'm not sure I am convinced. I think that many of the existing employees
are quite capable of optimising the existing bottlenecks, they probably just
aren't given any time to do so. The FastCode guys employ all kinds of
clever ASM tricks to squeeze every last cycle out of the CPU but I think
there is usually little difference between "as fast as possible" and "fast
enough". Some routines may not be fast enough but that wouldn't be too hard
to remedy.
--
Pete
====
Audio compression components, DIB graphics controls, ECO extensions,
FastStrings
http://www.droopyeyes.com
My blog
http://blogs.slcdug.org/petermorris/
jeffc
Maybe, this is probably true under the old Borland regime. But even under
the new DevCo maybe they are not as interested in improving the native VCL
at such low levels. However, their flexibility in the last 2 releases to
incorporate these FastCode functions into the RTL does state differently.
I am looking forward to more surprises in Highlander.
However, time and money must be spent where current Delphi developers are
most interested. From what I have seen in the NG and with talking to
other developers, they are most interested first in a very stable and
optimized IDE, next up is native Win32 VCL and code. Most right now are
not interested in .NET for current projects.
So I make this post here so that if others feel that these 2 things should
get focus in the Win32 VCL, they can speak up.
Eric Grange
native 64bit compiler + base libraries (System, SysUtils, Classes) and Unicode
compiler and library support (true Unicode, ie. UTF-8, UTF-16 and UTF-32, not
just stop at UCS-2 by making all "String" into "WideString").
Beyond that, they have to find and design language and compiler enhancements to
make multithreading easy, *implicitly easy*, so that you can make applications
that will make good use of those 16 core machines coming in 2007, without it
feeling like teeth pulling: go beyond TThread, go beyond explicit asynchronous
calls, go beyond having to manually place critical sections/semaphores/etc.
In short, right now, I'd rather see DevCo invest their time in what only *them*
are able to provide, rather than what us, users of DevCo products, can provide.
Eric
Bart van der Werf
"jeffc" <nos...@hotmail.com> wrote in message
news:44b73f3e$1...@newsgroups.borland.com...
> Well lets compare Delphi VCL to some modern frameworks in terms of
> Collections
I totally agree, i wrote a comlete set of typed and untyped arraylists,
linkedlists, hashsets and hashmaps
(especially using pointers to interfaces/strings while getting refcounting
right was fun) and it really helped our productivity.
We even banned TStringList for most uses becauses it preforms so badly
compared to our replacement. (especially the name/value map frankenstein)
grt, Bart
Bart van der Werf
"Peter Morris [Droopy eyes software]" <pete@NO_droopyeyes_SPAM.com> wrote in
message news:44b7494e$1...@newsgroups.borland.com...
>> What I really would like to see is the new DevCo hiring the FastCode guys
>> and let them work full time on this stuff.
>
> I'm not sure I am convinced. I think that many of the existing employees
> are quite capable of optimising the existing bottlenecks, they probably
> just aren't given any time to do so. The FastCode guys employ all kinds
> of clever ASM tricks to squeeze every last cycle out of the CPU but I
> think there is usually little difference between "as fast as possible" and
> "fast enough". Some routines may not be fast enough but that wouldn't be
> too hard to remedy.
It's not only the implementation, the datastructures and algorithms are also
lacking, no propert hashmaps and no simple to build O(1) head/tail mutation
arraylists, instead we get braindead feature bombs like TStringList.
grt, bart
Kevin Frevert
news:44b77fd2$1...@newsgroups.borland.com...
>we get braindead feature bombs like TStringList.
What is a "braindead feature bomb"? How does that correlate to the
TStringList?
krf
Bart van der Werf
"Kevin Frevert" <ke...@workdrinkingicewater.com> wrote in message
news:44b7...@newsgroups.borland.com...
It does alot of things, few of them well.
Personally i prefer simpler classes that do one thing well.
TStringList tries to be:
a list of strings (ok, it could be more intelligent about insertion and
removal at the head and tail of the list)
a set of strings (binary search is mostly ok, but insertion gets expensive
pretty fast)
a map of string to object (why add this ? it just makes it a confusing thing
and needlessly increases memory overhead of the previous two)
a map of string to string (Names/Values) (why is this in a tstringLIST class
? also the implementation is pretty horrible. replacing code that used this
by a proper hashmap improved performance incredibly for us)
All the utlity functions also make this class look like a more complex beast
then it really is.
grt, Bart
Nick Hodges (Borland/DevCo)
> But even under
> the new DevCo maybe they are not as interested in improving the
> native VCL at such low levels.
This is not true. I spoke to the RTL engineer yesterday. We're going
to look closely at TStringList, and maybe sic the FastCode guys on it.
We'll see.
We do not, however, take such changes lightly. Altering low-level
code like that is not something we do willy-nilly, for obvious reasons.
--
Nick Hodges
Delphi/C# Product Manager - Borland/DevCo
Read my Blog -- http://blogs.borland.com/nickhodges
Barry Kelly
> jeffc wrote:
>
> > But even under
> > the new DevCo maybe they are not as interested in improving the
> > native VCL at such low levels.
>
> This is not true. I spoke to the RTL engineer yesterday. We're going
> to look closely at TStringList, and maybe sic the FastCode guys on it.
TStringList is similar to TList, IMO - it should probably be kept
relatively lightweight.
Improving the performance of things like name/object lookup would entail
using a hashmap or something similar under the covers, which would
greatly increase its memory usage, even in all cases where that isn't
needed.
-- Barry
Marc Rohloff [TeamB]
> Well lets compare Delphi VCL to some modern frameworks in terms of Collections
That wasn't at all what I said. To put it another way, would you
rather have faster strings or say a native 64 bit compiler.
Jim Rowell
> TStringList is similar to TList, IMO - it should probably be kept
> relatively lightweight.
>
> Improving the performance of things like name/object lookup would
> entail using a hashmap or something similar under the covers, which
> would greatly increase its memory usage, even in all cases where that
> isn't needed.
A good alternative would be to add separate new fast classes and only do
improvements on the originals that don't have any potentially negative
effects.
--
Jim Rowell
RHR
> rather have faster strings or say a native 64 bit compiler.
Faster strings. 64 bit only provides more addressable memory. Yawn...
RHR
It's a huge black eye to Delphi.
Lars G
"RHR" <rr...@neosoft.com> skrev i en meddelelse
news:44b85c94$1...@newsgroups.borland.com...
Not true !
The 64 bit CPUs contain twice as many registers as their 32-bit counter
parts and each register is also twice as wide
Matt Jacobs
If you want those things use C++ and the Standard Library. ;-)
Matt Jacobs
>Today in these 2 spots (Collections and String processing), I believe that
>Delphi supports just the bare minimum. The FastCode project is a step in
>the right direction, but their focus is on improving the core RTL. In
>addition this is happening outside of DevCo and not on a full-time basis.
> Shouldn't this type of work be part of DevCo?
Those kinds of optimizations are not often included in desktop
frameworks because they don't provide a lot of bang for the buck.
High-speed collections and strings are of the utmost importance to
those who write servers because servers need to be as fast and
efficient as possible.
But for the average desktop application, one can get by fairly well
with the current collections and strings.
If more people were using VCL in servers, it would be an issue. But
like MFC, VCL was never intended to be a server framework and I don't
think a lot of people are using it to write high-speed server
software.
Bart van der Werf
"Matt Jacobs" <no...@noyb.com> wrote in message
news:8e6hb2lfc8bnfblhl...@4ax.com...
Are you suggesting delphi isn't upto the task of running on the server side
?
Or that people don't have intresting datastructures on the client ?
Anyways as i said in another post in this thread, i made a framework of
classes that indeed is something like what the STL provides. (altough more
like the 1.3 java collections if your nitpicking, no templating/generics
ofc)
grt, Bart
Pierre le Riche
> This is not true. I spoke to the RTL engineer yesterday. We're going
> to look closely at TStringList,
Something that should speed up TStringList and many other routines that make
use of strings is to improve the RTL and compiler magic to perform string
comparisons more efficiently. At the moment there is a single function
_LStrCmp in system.pas that does all string comparisons (equality,
inequality and greater/less checks). Apart from the fact that this routine
can be optimized, it is overkill for simple equality and inequality checks -
it always compares the character data even if the string lengths differ (so
it is often obvious beforehand that the strings cannot match).
I suggest that another string routine be implemented, called _LStrEqual,
that checks the string lengths first before unnecessarily comparing
character by character. I have logged this as QC#11916 (with a suggested
implementation included under "Steps").
If the compiler detects a "=" or "<>" comparison between two strings it
should emit code to call _LStrEqual instead of _LStrCmp.
The request for a better implementation of _LStrCmp is logged as QC#13920.
> and maybe sic the FastCode guys on it.
If these two suggestions (_LStrEqual function, faster _LStrCmp) are worthy
of consideration for inclusion in Highlander, then we could build two
challenges around them and submit the winning functions to you.
Regards,
Pierre
Kristofer Skaug
> If more people were using VCL in servers, it would be an issue. But
> like MFC, VCL was never intended to be a server framework and I don't
> think a lot of people are using it to write high-speed server
> software.
If DevCo improves the string collection support in RTL, perhaps they (users)
will... :-)
My apps are not particularly heavy in string processing but I do know that
some of the improvements suggested here would make a definite positive
impact .
--
Kristofer
Kristofer Skaug
<snip>
> improved RTL functions, but also creating a expanding the VCL by
> adding a better String processing library and a superfast and
> powerful Collections library (improved TStringList, etc).
I agree that the RTL, as the purring engine behind our apps, should be a
constant focus of improvement.
From D5 up to D2005, this has received far too little attention. Fortunately
the tide seems to be changing, with all the new FastCode stuff and the new
memory manager.
Perhaps you should fine-grain your request into a handful of more
"manageable" specific suggestions, though, and put those in QualityCentral.
--
Kristofer
Marco van de Voort
IMHO the biggest problem with tstringlist is the insertion/deletion slowdown
on ordered collections over say 100000 items. (D6) This because it is one
big array.
This can be remedied without compromising the current layout, since it only
means smartening up the internal layout a bit.
Matt Jacobs
I agree, but I'm not sure they should be included in the VCL.
Matt Jacobs
>Are you suggesting delphi isn't upto the task of running on the server side
>?
I don't think the VCL is optimized or designed for it, no.
>Or that people don't have intresting datastructures on the client ?
Sure, but the average desktop software does not need super optimized
strings like a server.
>Anyways as i said in another post in this thread, i made a framework of
>classes that indeed is something like what the STL provides. (altough more
>like the 1.3 java collections if your nitpicking, no templating/generics
>ofc)
Sell it! ;-)
Kristofer Skaug
> I agree, but I'm not sure they should be included in the VCL.
Well, surely optimizing TStringList wouldn't hurt!
(the improvements suggested by Pierre LeRiche above sound interesting
enough...)
--
Kristofer
Peter Morris [Droopy eyes software]
> using a hashmap or something similar under the covers, which would
> greatly increase its memory usage, even in all cases where that isn't
> needed.
But imagine a server with many connected clients where lots of TLists where
used per session just to keep a list of objects to clean up later. No fast
IndexOf would be needed in this case, but the extra memory usage might break
the server.
It's a tough decision to make :-)
Peter Morris [Droopy eyes software]
> that checks the string lengths first before unnecessarily comparing
> character by character.
I agree completely!
Sebastian Modersohn
This report seems to be private, unfortunately. Any chance it could be made
public?
--
Sebastian
Marco van de Voort
Hmm. One is the mbcs representation of the other string. What happens?
Unknown
The same as now. They're not the same.
In an ideal OO world, you'd create a new class MBCString derived from
AnsiString and overload all the usual operators. But I don't think you
can do that in Delphi (or C++ builder, IIRC)
- Roddy
Nick Hodges (Borland/DevCo)
> Any chance it could be made public?
Done.
jeffc
I reflected on this more over the weekend and re-read my first post. I
think my request to blend all these String libraries into the VCL is not a
great use of DevCo time. I realized in looking at most functions in JEDI
and FastStrings that they all use alot of core functions like Pos(),
Uppercase(), etc or roll their own for speed. So I feel that DevCo should
best focus on improving the core lower level string functions. In
addition if there is need for other core functions, then these should also
be added to the VCL. I believe FastCode guys are suggesting a lowercase
Pos(). It probably would not hurt for DevCo to work with the JEDI guys
and look at FastStrings to see where these core String functions can be
improved or added. Then I think its best that the individual developer
use the functions he needs. The community should also as the VCL improves
start removing their custom RYO core string functions and replace them
with the VCL ones. It looks like DevCo will be continuing their fine
collaboration with the Fastcode guys and hopefully some DevCo developers
can be allocated to spend time on these improvements as well.
However, in terms of better collection classes. I still firmly believe
DevCo needs to improve the native VCL in this area. It probably makes
best sense to create Win32 versions of the .NET collection classes. This
could be timed to coincide with the addition of generics to Win32. In the
meantime maybe working with the FastCode guys to at least improve the
performance of TStringList could not hurt. The collection framework in
.NET and Java is well thought out and had been improved over many versions
. So building on these ideas in the VCL makes sense.
I disagree with the post that suggests only server programming will really
benefit from better collection classes. I develop small Desktop
applications and using some tweaks, workarounds, and fixes to the
collection classes in the native VCL has improved my code substantially.
Any others feel the same about this?
How would I go about wording this for a QC request?
I will look to see what specfic QC items I can make concerning this
thoughts in the thread. But I could use some guidance on how specifics I
need to be since it will be my first QC contribution.
--- posted by geoForum on http://delphi.newswhat.com
jeffc
Right now - faster core string functions and better collection classes.
Unless someone is going to be doing server development or enterprise
database engine, I don't see the benefit right now.
I guess for me I am bias since my apps will be desktop only using a local
database engine. So most consumer users of the desktop are not going to
be moving anytime soon to 64-bit OS. First they need to upgrade the
hardware. I believe that Win32 is going to live for a long time before I
need to start even thinking about 64-bit. There are going to be lots of
Win32 users out there for awhile that are not going to be rushing into
64-bit.
I guess others needs may be different. I guess its up to DevCo to truly
measure their customers needs in terms of 64-bit over other choices.
I want 64-bit compiler also, but I think that other more pressing things
need to happen first.
I remember one company years ago that we bought development tools from.
They would annually hold an event where everyone was given ## amount of
dollars to spend on the features they needed most. The company would then
tally the results and focus on these features. There were lots of
giveaways in order to motivate people to participate. I thought this was
an great idea. Since if you took a poll today in a room full of customers
and said - okay who wants 64-bit. Almost everyone is going to say, sure
I'm game. But what they don't realize is that something else is going to
have to give to spend time on this feature. Maybe this is something the
new DevCo can do. I believe the list of items was also composed by both
the company and features that customers suggested prior to the event.
Eric Grange
> relatively lightweight.
TList isn't really lightweight actually, mostly because of its internal
notification scheme.
> Improving the performance of things like name/object lookup would entail
> using a hashmap or something similar under the covers, which would
> greatly increase its memory usage, even in all cases where that isn't
> needed.
Merely having the list sorted "by name" would provide a speedup of the
same order of magnitude as a hasmap or index in many scenario, at no
memory usage cost.
Eric
jeffc
>are quite capable of optimising the existing bottlenecks, they probably just
>aren't given any time to do so. The FastCode guys employ all kinds of
>clever ASM tricks to squeeze every last cycle out of the CPU but I think
>there is usually little difference between "as fast as possible" and "fast
>enough". Some routines may not be fast enough but that wouldn't be too hard
>to remedy.
>
>
>Pete
Pete, very good point. Yes, I think some small tweaks to code would
create a huge benefit. Its a good point that the FastCode way of doing
things is neccessary for these improvements to happen or neccessary to see
big gains in performance. As you say, FastCode guys are very detailed
about ultimate speed. I mean it is a competition they are creating. So
yes, I agree if DevCo developers could maybe focus on the things the
FastCode guys are not currently working on, then we could see some great
performance improvents to the RTL in every release with a combined
coordinated effort.
I guess its really up to us also, to tell DevCo what we want to see
improved in the RTL and VCL via the QCs. Maybe I can start up another
thread to gather QC suggestions based on this thread. I think quite a few
may already be in BDN QC, but we could point these out and get people
voting on them.
Eric Grange
> need to happen first.
Efficient containers replacement are available already, some have been
available for half a dozen years.
This isn't a "pressing" matter for us, and IMO this is a problem that
all self-respecting Delphi shops have already solved for themselves long
ago, either by getting libraries from 3rd parties or designing it
themselves.
I agree that for newcomers to Delphi that don't have any business
libraries, experience or codebase it could matter, but I don't think
there are many newcomers these days, nor do I think that enhanced
containers "out of the box" would make them come to Delphi.
Eric
jeffc
>available for half a dozen years.
Can you point some out?
I found these:
http://www.zeitungsjunge.de/delphi/containers/index.htm
However, I bet alot of these 3rd party ones, like the one above use alot
of pointers to gain speed and thus are not migratable to .NET. What you
get from having these improved collection classes become part of Delphi is
that DevCo provides the migration path for you to .NET when you are ready.
To me this is a huge reason that I want to see them spend time on getting
this into Win32.
>
>This isn't a "pressing" matter for us, and IMO this is a problem that
>all self-respecting Delphi shops have already solved for themselves long
>ago, either by getting libraries from 3rd parties or designing it
>themselves.
I use collections all over my code. Alot of use of TStringList and
TObjectList. I would prefer to have that much use in my code using core
RTL and VCL stuff rather than some 3rd party.
>
>I agree that for newcomers to Delphi that don't have any business
>libraries, experience or codebase it could matter, but I don't think
>there are many newcomers these days, nor do I think that enhanced
>containers "out of the box" would make them come to Delphi.
>
Sorry, I guess I would fit into that newcomer category. Even though I
purchased Delphi 5 first, I never really got my project off the ground due
to personal matters. But I am forging ahead with Delphi 7 now for the
last year.
It can't hurt a newly launched DevCo to improve the core native RTL and
VCL so that others looking at this language for native projects can see it
is up to snuff with the lastest frameworks out there if not better. I
have a feeling that some developers using .NET and WPF are going to come
looking elsewhere for speed. Delphi is a good choice for native apps
right now, with a great path to migration once WPF matures. So it makes
sense for this new company to make there product very palpable to others.
Eric Grange
RxLib had quite a few, JCL has others. There are a variety of scattered
classes, often there are some packed within other component libraries
for their own designs (GLScene has some f.i.).
> However, I bet alot of these 3rd party ones, like the one above use alot
> of pointers to gain speed and thus are not migratable to .NET.
Being non migratable can be a desirable feature, it's a sign of a
no-compromise design.
> What you get from having these improved collection classes become
> part of Delphi is that DevCo provides the migration path for you
> to .NET when you are ready.
The migration path to .Net isn't a very relevant issue IMO.
There has been ample demonstration since D8 that the Delphi users that
want to go .Net overwhelmingly take the C# route, not the D.Net one.
The only Delphi migration path that has a future is D64 IMO.
> To me this is a huge reason that I want to see them spend time on getting
> this into Win32.
These are just containers, if you want .Net support for them, you can
just wrap the .Net containers in Delphi-container clothes for your
migration purposes, and then replace them as you go.
Shouldn't take more than a few days to make all the
TList/TStringList/etc. wrappers you need, so IMO migratability of the
container classes is a different problem to making efficient container
classes, one of minor complexity that can be tackled independantly.
> I use collections all over my code. Alot of use of TStringList and
> TObjectList. I would prefer to have that much use in my code using core
> RTL and VCL stuff rather than some 3rd party.
What does RTL/VCL stuff only buy you over 3rd-party-with-source or
homemade? (seriously)
Unless DevCo really changes the way Borland did things, "RTL/VCL only"
buys you bugs that rarely get fixed (and when they do, it's years/months
after you've had to find a workaround/fix for yourself), inefficiency
(witness TList internals), misdesigns (TCollection/TCollectionItem)
along with forward compatibility troubles.
The whole power of Delphi IMO and IME has not been has much what came
with the box, but rather that you could extend/replace everything that
came in the box, something C++ offers, but VB didn't, and C# doesn't
fully offer either.
> Sorry, I guess I would fit into that newcomer category. Even though I
> purchased Delphi 5 first, I never really got my project off the ground due
> to personal matters. But I am forging ahead with Delphi 7 now for the
> last year.
Oh, then I guess you missed the "happy years" when Delphi stuff was
lively floating all around the web... I don't know exactly in which
state those sites are nowadays, but these are where we got pretty much
all our initial source, samples and components:
- Delphi Super Page
- Torry's
- Delphi Pages
- UNDU
> I have a feeling that some developers using .NET and WPF are going to
come
> looking elsewhere for speed.
They'll be looking C++ way I'm afraid, which they are likely to already
have unless they went for the cheapest of all Visual Studio boxes.
D.Net isn't a speed king in the .Net world (even when using .Net
containers and not Delphi containers), and that'll likely be what
they'll have looked at first, and then assumes DWin32 is no better since
it's older.
Eric
Jim Rowell
>
> I disagree with the post that suggests only server programming will
> really benefit from better collection classes. I develop small
> Desktop applications and using some tweaks, workarounds, and fixes to
> the collection classes in the native VCL has improved my code
> substantially. Any others feel the same about this?
I rely on TList and TStringlist quite a bit (a /lot/), often in areas where
speed is moderately important.
The problem is the current implementations are usually fast enough (barely)
for the purpose that I havn't done anything regarding improving them or
using other methods. OTOH, they are slow enough that I /wish/ they were
faster. Of course, the fact that the vcl itself makes heavy use of them is
also a good reason for speeding them up. I would seriously appreciate
improvements to them. They are on the short list of things I'd like to see.
--
Jim Rowell
Pierre le Riche
> This report seems to be private, unfortunately. Any chance it could be
> made public?
I have made a new report, QC#31328, that supersedes both these reports. The
new report contains improved functions based on the winner of the Fastcode
CompareStr challenge.
Regards,
Pierre
Ingvar Nilsen
> I rely on TList and TStringlist quite a bit (a lot)
Me too, both of them
> OTOH, they are slow enough that I wish they were faster.
I have an application that uses a very large TStringList, ~ 60 000
entries. When iterating this list, I increased the speed of my app
almost by a factor of 100 by just finding a clever way to find the
right starting point, it turned out starting at zero each time was not
needed at all.
--
Ingvar Nilsen
http://www.ingvarius.com
jeffc
reason for speeding them up
Very good point!
I wonder how much TStringList performance has benefited from the FastCode
changes in 2006. It would be interesting to see a comparison of D7
TStringList vs 2006.
Nathanial Woolls
> That wasn't at all what I said. To put it another way, would you
> rather have faster strings or say a native 64 bit compiler.
Faster strings
Liz
Faster strings
That way when its converted to 64, they would also inherit the speed
improvements too (at a guess)
--
Liz the Brit
Delphi things I have released: http://www.xcalibur.co.uk/DelphiThings
Jim Rowell
Amazing how little things become massively important on big lists or files,
isn't it?
I presume you know about the "sorted := false; load stuff; sorted := true;"
thing?
Dejan Stankovic
> That wasn't at all what I said. To put it another way, would you
> rather have faster strings or say a native 64 bit compiler.
>
What kind of argument is that? I'd understand it if it was about some
open-source project, but for $2000-$3000 professional tool?
Ingvar Nilsen
> Amazing how little things become massively important on big lists or
> files, isn't it?
It is a different world, yes
> I presume you know about the "sorted := false; load stuff; sorted :=
> true;" thing?
Yes, but in this case it cannot be used
Bart van der Werf
"Eric Grange" <egra...@SPAMglscene.org> wrote in message
news:44bb460a$1...@newsgroups.borland.com...
>> I want 64-bit compiler also, but I think that other more pressing things
>> need to happen first.
>
> Efficient containers replacement are available already, some have been
> available for half a dozen years.
>
> This isn't a "pressing" matter for us, and IMO this is a problem that all
> self-respecting Delphi shops have already solved for themselves long ago,
> either by getting libraries from 3rd parties or designing it themselves.
So obviously this is an area where delphi is missing some stuff because
shops themselves are all inventing wheels of their own.
> I agree that for newcomers to Delphi that don't have any business
> libraries, experience or codebase it could matter, but I don't think there
> are many newcomers these days, nor do I think that enhanced containers
> "out of the box" would make them come to Delphi.
Not providing them because of these reasons if fatalistic ;p
Providing this stuff is not hard to do, it's just catching up with the
competition.
grt, Bart
Rick Carter
>competition.
What a naive statement! I don't know what you've worked on personally,
but the Delphi team has a much more complex job than most of us
application developers working in Delphi. See Allen Bauer's last post.
>grt, Bart
Are you growling at us? What's with the "grt?"
Rick Carter
cart...@despammed.com
Chair, Delphi/Paradox SIG, Cincinnati PC Users Group
Brion L. Webster
>>grt, Bart
>
>Are you growling at us? What's with the "grt?"
I'm guessing it's a contraction of groetjes, or greetings.
--
-Brion
There's no such thing as 'one, true way;'
- Mercedes Lackey
jeffc
the issues with the design and performance of the container/collection
classes in the VCL.
Re: Biggest Delphi bottleneck?
http://groups.google.com/group/borland.public.delphi.language.basm/browse_thread/thread/b841bf994ee9b851/15b273668f389a9b?q=Biggest+Delphi+bottleneck%3F&lnk=ol&hl=en&
I believe some small tweaks can be made to help the current collection
classes. However, I do think they require a redesign. Take for example
that every collection framework I mentioned previously all have a
HashedList front and center in their collection classes. Yet, Delphi's is
buried in IniFiles unit and still has some issues.
I will be creating another thread to propose how this redesign should
happen. This will be used to form the basis of a QC that I will create.
Many of you have much more knowledge in this area than I have, so I am
hoping you will all contribute even if you feel it is something that
should be addressed later then sooner. Of course you know my stand on
that point ;)
Hopefully I can get Marco interested in this new thread since his article
illustrated he had a very good knowledge of issues in the current
implementation and probably has lots of ideas for a redesign. Marco??
I really look forward to some newbie coming along someday and redesigning
his .NET app natively in Delphi and then writing mounds of joy on how much
faster it is and how well the core string and collection classes in Delphi
are designed and perform. Not too mention how much easier he found the
VCL to work with than WPF and how it performed much better. And the fact
that he can still move to .NET easily when he wants to.
BTW - I am thinking of titling this new thread "Redesign of native
container/collection classes". If anyone thinks a better title is
fitting, then let me know. At the top of the post I will explain the
reason for the post, what info we are looking for, and what the proposed
outcome is (QC).
Brian Moelk
>> Well lets compare Delphi VCL to some modern frameworks in terms of Collections
>
> That wasn't at all what I said. To put it another way, would you
> rather have faster strings or say a native 64 bit compiler.
I agree with Jeff here. Delphi needs to have string processing and
collections improved to remain competitive.
If they have to choose between better string processing and a 64-bit
compiler, then DevCo really doesn't have enough resources or the right
ones. I understand the whole "limited resources" argument and made such
an argument in regards to .NET (but let's not go there). But constant
enhancement of existing libraries/frameworks should also be done, not
just the porting of them. ;)
I'm a big proponent of focusing DevCo's resources on the things that
developers really use and I agree with Jeff completely that string
processing and collections are fundamentally important things.
If you're talking about marketability of features, I agree, strings and
collections aren't sexy at all, but they would definitely please the
current customer base and give them a good reason to upgrade.
--
Brian Moelk
Brain Endeavor LLC
bmo...@NObrainSPAMendeavorFOR.MEcom
jeffc
>shops themselves are all inventing wheels of their own.
Bart I agree with this as well. If you read the original point of my
email post, it was that these core classes/functions that we use in 50% of
all our developement should be improved by the Delphi team. A development
language at its most core should support the core 50% of code we write and
we should not have to look outside the language for these.
Eric, your stance is that it takes Borland forever to fix these and there
are other options out there so just leave it as is. I strongly disagree
on this explanation. DevCo is changing and is asking for our input on
things we want to see changed, which is what motivated this thread. This
is core stuff we all use and is also used in the VCL itself. Not to
mention that newbies coming to give Delphi a look at Delphi under the new
DevCo should not be disappointed with the core language functions.
Someone in a post I once read mentioned that the first thing they do after
the Hello program is to start working with collections and see how well
designed and implementable they are. I have a feeling thats a common
strategy for most people evaluating or first looking at a language.
DevCo is going to obviously gear up Delphi/BDS marketing unlike what we
have seen at Borland. And when those fresh faces come a knocking at
Delphi's door, they should be met with a smile. Hence the need for
improvements to bring Delphi's native core lang and frameworks in line
with what is available today in other Languages Frameworks and core lang.
My stance is that they should use the control they now have to fix what
isn't done right and then move on to the goodies. Tidying up the core
VCL, fixing VCL and RTL issues, and fixing the quality of the IDE should
be first after the syncing of BDS to .NET 2.0
Eric, in another post that I actually reference towards the end of this
thread you state:
"IMO, pretty much all of Contnrs.pas is up for at least a reimplementation."
Which sounds to me like you agree that they need a redesign. So I think
the only point we disgree on is the timing of these changes.
I am going to create another thread in which I will propose how a
reimplementation of the container/collection classes in Delphi should be
done. It seems to me you are actually alot more knowledgable about this
stuff then I am. So I would greatly value your input in this proposed
thread. Then we will create a QC based on this and leave it up to DevCo
to gauge the intrest in this and when it should be done.
Jon Robertson
>I am going to create another thread in which I will propose how a
>reimplementation of the container/collection classes in Delphi should be
>done.
If you do, please place it in an appropriate technical newsgroup.
Thanks
Bart van der Werf
"Rick Carter" <cart...@despammed.com> wrote in message
news:44bd...@newsgroups.borland.com...
> >Providing this stuff is not hard to do, it's just catching up with the
>>competition.
>
> What a naive statement! I don't know what you've worked on personally,
> but the Delphi team has a much more complex job than most of us
> application developers working in Delphi. See Allen Bauer's last post.
Having implemented such a framework for the shop I work at (10 base classes,
(circular)arraylists, hashmaps, a few dozen hashfunctions for all sorts of
data, about 50 typed wrappers, and unittests)
I'm totally unconvinced that this is a hard or even a big job.
>
>>grt, Bart
>
> Are you growling at us? What's with the "grt?"
GReeT: i guess it can be confusing
,Bart
Eric Grange
Many Delphi users never got beyond DB-aware components and implementing
events, merely designing a TList clone (or any class for that matter)
would prove a challenge to them, I guess these are the ones Rick is
referring to.
Eric