Return-Path: Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 83749 invoked by uid 500); 27 Jun 2003 16:05:16 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 83735 invoked by uid 500); 27 Jun 2003 16:05:16 -0000 Received: (qmail 83731 invoked from network); 27 Jun 2003 16:05:16 -0000 Received: from junior.lgc.com (134.132.72.99) by daedalus.apache.org with SMTP; 27 Jun 2003 16:05:16 -0000 Received: from lgchvw01.lgc.com (lgchvw01.lgc.com [134.132.93.107]) by junior.lgc.com (8.11.7/8.11.3) with SMTP id h5RG49s23912 for ; Fri, 27 Jun 2003 11:04:10 -0500 (CDT) Received: from 134.132.93.152 by lgchvw01.lgc.com (InterScan E-Mail VirusWall NT); Fri, 27 Jun 2003 11:05:17 -0500 Received: by lgchexchbh.ad.lgc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jun 2003 11:05:16 -0500 Message-ID: From: Dominique Devienne To: Ant Developers List Subject: About , , and buffer sizes Date: Fri, 27 Jun 2003 11:05:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Today I evaluated the various ways I could download a file efficiently. So I played with , using both the HTTP and FILE protocol, and with (see build file below). The file I'm downloading is 38,448,695 bytes long. The output of running each target twice is also shown below. So what is this all about? Well, the HTTP protocol is slower than the FILE protocol, but I expected that, because the HTTP server is serving files that reside on another NetApps filer machine (used to be faster when serving from its own disks). Note though that even though the file: protocol is faster, is not "smart" as implemented by , i.e. it always redownloads, even when the local copy is up-to-date. (note that the bigshot HTTP server is serving the same file from afiler1). I then tried out copy, which I know to be smart, and expected to be as fast as with the file: protocol. But to my surprise, it's not at all, and is in fact more than TWICE slower!!! A quick look at the code reveals that uses a 100*1024 bytes buffer, when uses a 8*1024 bytes buffer. This seems to have quite an impact on download performance!!! Given this information, I'd like: 1) to be made "smarter" for the file protocol 2) to be made faster by adding the ability to control the buffer size used, as was recently added to I believe. In my particular case, I'd prefer (1), to be able to switch easily from http: to file: without having to change my build files (just the URL prefix used). I'll probably try it myself soon. (2) would be good too, and is probably simple to implement. Just a head's up. I don't recall anybody noticing something like this. Cheers, --DD P:\com_lgc\buildtools>build -f get.xml get.http Buildfile: get.xml get.http: [GET] Getting: http://bigshot.ad.lgc.com/dsbuilds/dsinfra/HEAD/latest/module-dsinfra.zip BUILD SUCCESSFUL Total time: 1 minute 7 seconds P:\com_lgc\buildtools>build -f get.xml get.http Buildfile: get.xml get.http: [GET] Getting: http://bigshot.ad.lgc.com/dsbuilds/dsinfra/HEAD/latest/module-dsinfra.zip Not modified - so not downloaded BUILD SUCCESSFUL Total time: 1 second P:\com_lgc\buildtools>build -f get.xml get.file Buildfile: get.xml get.file: [GET] Getting: file://afiler1.ad.lgc.com/dsbuilds/dsinfra/HEAD/latest/module-dsinfra.zip BUILD SUCCESSFUL Total time: 25 seconds P:\com_lgc\buildtools>build -f get.xml get.file Buildfile: get.xml get.file: [GET] Getting: file://afiler1.ad.lgc.com/dsbuilds/dsinfra/HEAD/latest/module-dsinfra.zip BUILD SUCCESSFUL Total time: 25 seconds P:\com_lgc\buildtools>build -f get.xml copy.file Buildfile: get.xml copy.file: [GET] Copying 1 file to P:\com_lgc\buildtools BUILD SUCCESSFUL Total time: 1 minute 8 seconds P:\com_lgc\buildtools>build -f get.xml copy.file Buildfile: get.xml BUILD SUCCESSFUL Total time: 1 second === ${ant.project.name} Build === --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org