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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8de7eedad50552f1 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newsread.com!newsprint.newsread.com!newsfeed.stueberl.de!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!news.task.gda.pl!not-for-mail From: jtg Newsgroups: comp.lang.ada Subject: Re: Ada bench : count words Date: Mon, 28 Mar 2005 21:54:32 +0200 Organization: CI TASK http://www.task.gda.pl Message-ID: References: <87vf7n5njs.fsf@code-hal.de> <423f5813$0$9224$9b4e6d93@newsread4.arcor-online.net> <18arnvu705ly4$.1wz6ybz1jt70y$.dlg@40tude.net> <1q9cx4jt7802s.k45m6mcntl87$.dlg@40tude.net> <460oxs2p0hbc.yjqxjeasx37r.dlg@40tude.net> <1spfhtlo4ya1w.1a8leo0bqclk8.dlg@40tude.net> NNTP-Posting-Host: pwr74.pwradio.pl Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: korweta.task.gda.pl 1112039672 25290 153.19.176.74 (28 Mar 2005 19:54:32 GMT) X-Complaints-To: abuse@news.task.gda.pl NNTP-Posting-Date: Mon, 28 Mar 2005 19:54:32 +0000 (UTC) X-Original-Organization: CI TASK http://www.task.gda.pl In-Reply-To: X-Accept-Language: pl, en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Organization-Notice: Organization line has been filtered Xref: g2news1.google.com comp.lang.ada:10089 Date: 2005-03-28T21:54:32+02:00 List-Id: Dmitry A. Kazakov wrote: >> >>IMHO the challenge is OK. Look at the system commands (in UNIX). In >>many cases text I/O performance is crucial. But since >>existing commands are very fast, nobody even thinks about it. > > > Ah, you hit my sore spot! In my view this is the problem of bad design. It > is characteristic of UNIX which said has three mouse drives, one per > button, but only for UNIX. [ The famous idea of splitting an application > into a chain of tiny commands like wc, sort etc is attractive but > altogether wrong. There is no universal way to do it. Then what about pipes > overhead and need of multiple re-scans. I don't buy it, and scripting > languages too. ] > It depends on what you are doing. Maybe you just didn't encounter problems that needed scripting languages or pipe chain. From my own experience I remember a tiny awk script I assisted to create, which needed a minute to automatically perform a task that usually took one day of human-assisted work with office tools. It took several minutes to create the script itself. "Office people" then looked at it and spent some time to create "office interface" in VB, that was just GUI for the script. They didn't even think of writing its contents in VB. And if they did, it would take several days to create, test and remove bugs from the program (integrated awk, diff and several other functions, and file I/O too). The way wc and other UNIX commands cooperate is briliant, it is the right way to do certain things and it does not exclude other ways of solving other problems. If you need Office, you can run it, even on UNIX. What's the problem? > > > In my experience, GNAT always had bad performance, and not only in > Ada.Text_IO, which is a minor problem for the mentioned above reasons, but > in far more important parts. As for patching GNAT, well, maybe next time... > (:-)) Anyway Ada.Text_IO performance is not on the top of my list. I'd > better improve ADT, add full MI and MD, make T'Class for all types, tasks > and protected types tagged, allow multiple parties rendezvous etc. (:-)) > Well... I don't need it either. Maybe Ada programmers don't need Text_IO performance. > >>Or to notify GNAT team about the >>problem. It would not only give Ada better >>position in this challenge, but also speed up text I/O operations of >>all the programs compiled with future versions of GNAT. > > > If you are a paying customer of ACT, you can try... (:-)) > No. I was just fascinated with all the efforts shown in this thread. :-)