Date: Wed, 3 Aug 2005 08:55:53 -0600 (MDT) From: "Ryan Sommers" <ryans@gamersimpact.com> To: "Luigi Rizzo" <rizzo@icir.org> Cc: maxim.sobolev@portaone.com, "current@freebsd.org" <current@freebsd.org> Subject: Re: Sub-optimal libc's read-ahead buffering behaviour Message-ID: <1099.66.166.104.222.1123080953.squirrel@66.166.104.222> In-Reply-To: <20050803071651.A84608@xorpc.icir.org> References: <42F0CCD5.9090200@portaone.com> <20050803071651.A84608@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo said: > On Wed, Aug 03, 2005 at 04:55:33PM +0300, Maxim Sobolev wrote: >> Hi, >> >> I have found the scenario in which our libc behaves utterly >> suboptimally. Consider the following piece of code reads and processes >> every other 512-bytes block in a file (error handling intentionally > > apparently the issue is in fseek(), you should try to track > why fseeko() it goes to the 'dumb:' label where it simply discards the > buffer and does the seek... > ... other stuff omitted ... Looks like the reason it might go into dumb is because he's using SEEK_SET instead of SEEK_CUR and then hitting: if (!havepos && _ftello(fp, &curoff)) goto dumb; havepos only gets set if the SEEK_CUR switch is hit (oddly enough looks like this could be considered a bug since we are relying on the fact that havepos is zero'd when it is allocated, however, I haven't had ample time to say conclusively). Try using SEEK_CUR and skipping your buffer size each time. -- Ryan Sommers ryans@gamersimpact.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1099.66.166.104.222.1123080953.squirrel>