Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: byte stream vs char stream buffer Date: Sun, 11 May 2014 16:02:40 +0200 Lines: 40 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net ptg3qx5rZGlOufVSpXvyJQO6K4HfLWLqPcE5F1Y5DvLspOoKg= Cancel-Lock: sha1:i6N8lsaNKDchyTPoAXOeR1l+d3Y= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:28435 On 11.05.2014 01:08, Roedy Green wrote: > On Sat, 10 May 2014 23:24:57 +0200, Robert Klemme > wrote, quoted or indirectly quoted > someone who said : > >> I find this a fairly unspecific description of the test you did. We do >> not know what your test did to ensure file system caching or GC effects >> did not influence the measurement etc. > > the code is posted at > http://mindprod.com/applet/fileio.html#BUFFERSIZE I followed a slightly different approach and modularized my test a bit more. You can find it here: https://gist.github.com/rklemme/fad399b5e7cc4d3b6d0c File opening and closing is not measured. You can assume the data to purely come from memory (vastly more mem than file size + no disk activity shown). This was on an Xbuntu 14.04 64 bit, kernel version 3.13.0-24. No special JVM command line switches were used. > These are not particularly subtle effects. I ran five trials and took > the best time for each. I figured this would eliminate hotspot > initialisation and GC effects. Sounds good. I followed the same approach (i.e. repeating and using the min time value). My results: - The higher level the buffering, the more effective. - Buffering on byte level often actually rather hurts than helps. - Reading in 1k chunks from the application level is already close to optimal. Kind regards robert