String speed in D1(short) vs. D2&D3(long)

null
jodylAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jodylAuthor Commented:
Edited text of question
0
jodylAuthor Commented:
Edited text of question
0
andrewjbCommented:
Long string handling is 'clever' in that long strings have a reference count. If you assign string A to string B, then the reference count is simply updated. If you later alter string B, the reference count goes down, A still points to the original, but a completely new string ( with reference count 1 ) is created for B.

This means there is a fair overhead in sorting out these reference counts. Short strings are simply 256 characters long, full stop, so the overhead doesn't exist.

0
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

jodylAuthor Commented:
Yes, I know that this is how Delphi is handling strings.  I did read the help about long strings.  Although I wouldn't call the way copying of long strings is done 'clever'.  How often would you copy a string and NOT do anything to it?  The reference count seems to me to be unnessasary overhead.

What I'm trying to find out is whether or not D3 is any faster? If it is, then I'll probably purchase it, just to save myself the  reprogramming time.  If it's not, then I have some serious changes to make to my program.  Reading in less than 1M of specifications shouldn't take longer to do than the complex processing a 10M data file.

Jody

0
mirek071497Commented:
I think so in your example is possible to slow down processing. This depends on your algorithm, but you can rewrite your procedures to new delphi style and then this must be faster than with delphi1. If you find any difficulties with rewriting the code for delphi2 than submit here question about this with some example code.
0
ergatesCommented:
There are some key differences between short and long strings which can lead to some "gotchas". First a recap:

A short string has a fixed maxumum size, up to 255 because the size is stored in byte. I don't understand your reference to garbage collection under Win95, I couldn't find this in the help. You can allocate short strings (with new or getmem) on the heap, but you are responsible for freeing them, they will not be freed automatically.

Long strings have a four byte length, and *always* have a dynamic portion that grows according to the current length of the string. You shouldn't need to worry about how it does this, but be careful that some of the operations for short strings are different, e.g. using s[0] to access the length byte doesn't work.

I think the problem could be that you are frequently trying to extend the length of a string. In a shortstring, this is quick, because it all takes place within the 'string' already allocated Consider adding a character to a string, using s := s + 'a'. This takes 3 steps, find the length of s, put 'a' in position length +1, increment length. This can be done in a handful of machine instructions and is very quick.

For a dynamic string, if the buffer Delphi allocated isn't big enough to add the 'a', its got to:
1.Allocate a (bigger) new string from heap.
2.Copy the old string to the new string.
3.Deallocate the old string.
4.Put the 'a' at the end and increment the length.

The extra 3 steps inolving memory management and copying are really slow in comparison.

There is a speed advantage to long strings in that if you pass one to a procedure as a value parameter, it doesn't need to copy it, but long strings can also be slower due to the extra overhead of memory management.

The two big plusses are, obviously, longer strings, and completely dynamic use of memory, which are the two major problems I always had with shortstrings. So while long strings are generally 'better', you may find cases where you hit a downside, particularly if you are hitting the string handling hard.

You may be able to get round the problem by presetting the long strings to allocate a large buffer, then set them to '', but I'm not sure if this works. In the meantime it might be best to stick with short strings, a pain I know.

This applies to D2, I haven't got D3 yet!

Regards,


0
jodylAuthor Commented:
I already know this.  I've read the help file about how strings work.  The info about garbage collecion and short strings is in one of the help topics that compares short and long strings.

Since no one seems to know whether or not D3 is anymore efficient than D2 as far as the string manipulation is concerned, I'll just have to check this for myself.  Although I don't hold much hope that it'll be any faster.  Null-term strings look like they'll be the best way to handle this.


Jody

0
jodylAuthor Commented:
Since the only answers I'm getting concerning Q1 & Q2 are repeating information out of the help file (which I have already read), I'm only interested in an answer to Q3:

Does D3 handle long strings faster than D2?


Jody

0
mirek071497Commented:
mayby 10-20% but not more.
0
ergatesCommented:
D3 may handle strings slightly faster than D2, but it isn't going to magically solve your problem.

Short strings do not take part in any garbage collection, automatic or otherwise, unless this is something you have programmed yourself. Long strings will only be faster in the specific case of copying strings, in general they will be slower than shortstrings, in specific cases such as yours they may be a lot worse. The point of longstrings is size and dynamic allocation, not speed.

I can suggest two concrete ways to solve your problem with a minimum of effort:

1. Use shortstrings. These should work exactly the same way as they did before. If you encounter a problem, it's due to something else. I suspect you may have some other memory leaks that manifest under win95.

2. 'Preallocate' the long strings before you use them. You could use SetLength(str,256) to do this.

I have suggested a reason why the code may be a lot slower using longstrings, but without seeing your code I can't be sure. Could you let us know if the code does a lot of "string1 + string2" type operations?

Rewriting your code to use null-terminated strings is going to be a lot of effort, be very messy and introduce obscure bugs. You will have to rewrite all your string expressions to use strcat etc.

Ultimately whether using D3 will restore the performance of your application is only something you can tell us, unless you can send us some sample source which we could have a look at. I'm sure I could improve the D2 performance, and I have D3 on order.

I think the questions that you did ask have all been answered correctly, but as I say there is no magic answer to your problem. I could have said No, No, Yes and No, but I didn't think that was what you were looking for!

If you try D3, good luck, but I think you already have the answers.

Regards,
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jodylAuthor Commented:
A small speed increase was what I had expected to hear.  Yes, in one place it does a lot of "String1 := String1 + String2" operations, but only when it's reading in a specifications file for display.  It does alot more of "record.stringX := SubStr( String )" type operations when it's reading in the spec file for actual use and this is just as slow.

I'm just going to shelve the conversion to 32-bit for now.  I have too many other enhancements to this appliction waiting.  

I also do a fair amount of programming in C, so dealing with null-term strings isn't a big deal.  To simplify this I've already isolated the places where I'd need to deal with this into just a couple of functions so that I don't have alot of places to add the memory allocation and deallocation routines.  


Thanks for your help.

0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Delphi

From novice to tech pro — start learning today.