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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,68494635acddb77e X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 23 Aug 2008 08:40:59 -0500 From: "Steve" Newsgroups: comp.lang.ada References: <60a35fd4-e5a6-4aa0-a73f-6815ce7e92fc@f36g2000hsa.googlegroups.com> <4af2f934-7458-4370-b325-c38e3a4068b8@s50g2000hsb.googlegroups.com> <1jt8nguvzf1hw$.189glcey6hmht.dlg@40tude.net> <84805bfc-26f4-4507-9024-9e3558c9cb32@m73g2000hsh.googlegroups.com> <104g44sstk0to$.1lektfatijska$.dlg@40tude.net> <4db7770e-a53b-436b-bc87-b487fdec430b@e39g2000hsf.googlegroups.com> <1n1jam128sz9v$.3jl0ijmar2gb.dlg@40tude.net> <6242f0d9-4874-427d-bf45-c5f5c36c75f2@k7g2000hsd.googlegroups.com> Subject: Re: File output and buffering Date: Sat, 23 Aug 2008 06:41:07 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Message-ID: X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 24.20.111.206 X-Trace: sv3-MfJ2/D2bKvV1TkqnzOIuPbcGVW2nykSzSQ99KHJ48j7B+qYhL7xh/FeTLrUkCImwWtr9xnA3DBIKrOg!UrqGyPqN6FdMv+5LQKXQ+JksbIfYfPpd/9wDoekPfLOiA7cPJ2E7F5PbS1eypM6O6Ftff2Bb7HKd!vcM+8qyFU1n/wJ/FdiQsBe7HOXUpTw== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.39 Xref: g2news2.google.com comp.lang.ada:7508 Date: 2008-08-23T06:41:07-07:00 List-Id: "Dmitry A. Kazakov" wrote in message news:yiw2f938342v.xzb47swyx5h4$.dlg@40tude.net... > On Fri, 22 Aug 2008 14:41:18 -0700 (PDT), Maciej Sobczak wrote: > >> On 22 Sie, 15:22, "Dmitry A. Kazakov" >> wrote: >> >>> One last try. In your example, when >>> characters of a message are sent *synchronously* (assuming E-mail as the >>> transport layer, no back doors, etc) then each single character has to >>> be >>> sent as a reply to the answer to the earlier mail. >> >> Then we have a different notion of "synchronously". >> When I write something to the file, the operation is synchronous when >> the program *waits* for the transfer to complete. > > The transfer of the group, not the transfers of the individual items of. > Dmitry, I have read enough of your posts on this newsgroup to know you're not a troll, but is sure hard to tell from reading this thread. In my experience (theory aside) sending one character a time to an OS is considerably slower than buffering the data and sending blocks of data. Several years ago I rewrote a driver on one of our system that we used to communicate serially (using RS232) with a PLC (Programmable Logic Controller). The driver was originally written to make separate calls to the OS for each character sent to the PLC. The original implementation utilized approximately 15% of the CPU. When I re-wrote the driver to buffer the characters into blocks of up to 128 characters (defined by the PLC protocol) and make one OS call for the buffered data, the CPU utilization dropt to less than 1% of the CPU. This behavior makes perfect sense to me because for each call to the OS a buffer is allocated containing the data to be transmitted and placed in a queue for the OS. The buffer itself contains more than just the data to be sent, it includes some overhead, sometimes significant in size. The addition of the buffer to the OS queue often includes considerable overhead, context switches, mutexes, etc. When the number of characters in the buffer is increased the overhead is not significantly increased. Sure, if you're talking directly to hardware hardware that only handles one character at a time then buffering and unbuffering data adds overhead. But it is rare in these days to talk directly with the hardware. Even the simpler systems often use a kernel or OS that makes buffering worthwhile. If you're using TCP/IP to send data, if you're going to send a bunch of data at a time it would be silly to send one byte at a time. IP has considerable overhead for each block. You should try to include as much data as possible to minimize the number of packets sent and minimize the overhead. I find it interesting that you seem to be arguing that it is always better to not bufffer, when the original poster has indicated that he has tried both buffered and unbuffered approaches and observed thant unbuffered was considerably slower on his system. Either you are miscommunicating or you are just plain wrong. Regards, Steve > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de