From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e6c9800e35ccfeee X-Google-Attributes: gid103376,public From: Jakob Heinemann Subject: Re: GNAT: Performance of String functions Date: 1997/07/22 Message-ID: <33D4DC7B.D8EEA39A@ericsson.com>#1/1 X-Deja-AN: 258154620 References: <33CF3908.3DF62EEE@ericsson.com> X-Priority: 3 (Normal) Organization: Ericsson Saab Avionics AB Newsgroups: comp.lang.ada Date: 1997-07-22T00:00:00+00:00 List-Id: Hello again! Thanks for yor discussion on my question about string speed. Your answers got me looking in the right direction and it no longer looks like a = string-comparing performance problem. = But first I will comment mr Dewar's letter, and at the end you will get presented the actual problem and its solution. Robert Dewar wrote: > = > A couple of notes. First all strings are passed by reference in all cas= es, > so that is definitely not an issue. Good. = > I doubt you could have an equivalent algorithm in VAX Pascal, although = I don't > know VAX Pascal that well. = Well, your doubts fails you. It is the SAME algoritm, it has been translated mechanically, and modified in minimum way to use ada functions were applicable. But the overall algoritm of the translated program is the same. The VAX-pascal = is also modular so things are wrapped in packages the same way as in the old code. Certain Pascal concepts have been exchanged with ADA equivs, systems calls are of course new. One of these is strings and strings comparison. One mistake, perhaps = is that vax-strings have been replaced with unbounded strings instedad of bounded s'. > In particular, what does the VAX Pascal use -- I > bet it either uses the equivalent of bounded strings, or it does not ha= ve > automatic finalization. = The VAX-pascal strings are really the same as bounded strings, yes. = > The unboundedness you certainly pay a price for, > and you also pay a price for the automatic finalization. But HOW MUCH penalty is there for this finalization? = ! Actually really ALOT! > And also, it would be interesting to see a distilled benchmark. = > When we look at such code, we often find it is apples vs oranges compar= isons, > and that in particular if some foreign language code has been simplisti= cally > translated to Ada, it has ended up as non-idiomatic Ada which can be ex= pected > to run slower. A factor of 10x smacks of that kind of phenomenon. Well, I agree to som point that simplistical translation sometimes generates rude and inefficient code. But dont=B4t forget, the pascal language is no= t that far away from Ada, of course a lot of nifty stuff is missing in Pascal, so when translating to Ada, nothing really has to change, neither code structure or the data structures have to change. Well, at least not in my case, since there is a stright off line, single process, program that is really a compiler/linker system. But in our project, of porting this particular code, what you describe is = what happened. A piece of code, very small, got converted, *and* fixed in a wrong way. = The problem was: In a little routine called to extract a few strings from a list (array of pointers) there was a sorting algorithm. It was bubble sort, not very famous for great = speed. I found out that the routine for getting the sorted list was called 6 times each execution and ity consumed 95% execution time. = Here is the code fragment for doing really SLOW sorting: SHIFT :=3D true; while shift loop shift :=3D false; for i in 1..nr_of_strings_to_sort loop if vax_fixed_gts(tab(i-1).all, tab(i).all) then tmp :=3D tab(i-1); tab(i-1):=3D tab(i); tab(i):=3Dtmp; shift :=3D true; end if; end loop, end loop; The table is an array of pointers to unbounded strings. Most time was spent = somewhere in this loop, looking closer to the gts (greater string) function revealed out of date patcheds for making vax-comparing speedy. There vere unneccesary padding of the strings to equal length. This must have caused a lot = of cleaning up-operations on the heap. Solution: = I threw out that sorting routine and made a new one, a qsort and one of the sortings went from 16.5 s to 0.017 s. The overall timing went from 40 minutes to 3 min. So I've qut blaming the unbounded strings for comparative slowlyness. = > = > The GNAT code for unbounded strings is relatively straightforward (you > can look at it easily!) There may be places it can be speeded up, but t= here > is nothing like a 10x factor of inefficiency in the coding that I know = of Yes, I've had a look and it doesn't seem to be that complex. Well, thanks for your attention, /Jakob :)