ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzau8_5.4.0.1/bufferio.htm

85 lines
5.3 KiB
HTML
Raw Normal View History

2024-04-02 14:02:31 +00:00
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en-us" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="security" content="public" />
<meta name="Robots" content="index,follow" />
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
<meta name="DC.Type" content="task" />
<meta name="DC.Title" content="Expanding buffer I/O through HFS" />
<meta name="abstract" content="Read about tailoring read requests for performance and to expand buffer I/O in HFS." />
<meta name="description" content="Read about tailoring read requests for performance and to expand buffer I/O in HFS." />
<meta name="DC.Relation" scheme="URI" content="tipsandtechniques.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2000, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2000, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="bufferio" />
<meta name="DC.Language" content="en-us" />
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
<link rel="stylesheet" type="text/css" href="./ic.css" />
<title>Expanding buffer I/O through HFS</title>
</head>
<body id="bufferio"><a name="bufferio"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Expanding buffer I/O through HFS</h1>
<div><p>Read about tailoring read requests for performance and to expand
buffer I/O in HFS.</p>
<div class="p"><div class="p">An alternative method of opening a stream file through HFS can
improve performance for applications that typically read portions, but not
all, of the data in large optical files. This alternate method of input/output
is referred to as <dfn class="term">expanding buffer I/O</dfn>. Expanding buffer I/O
is available only to HFS API applications when accessing High Performance
Optical File System (HPOFS) or ISO 9660 formatted media. This attribute is
ignored when the media format is UDF.<div class="note"><span class="notetitle">Note:</span> Using the HFS APIs, optical file
data is buffered into a virtual optical file in i5/OS™ main storage. If expanding buffer
I/O is not selected as an option, the size of this buffer is equal to the
size of the actual optical file. For example, a 100 MB file on optical media
has a 100 MB buffer when the file is opened through the HFS API Open Stream
File. The performance cost for overhead operations involving the optical buffer
is proportional to the buffer size. The time it would take to read one byte
of a 100 MB file is substantially greater than reading one byte of a 50 KB
file.</div>
</div>
<p>When an optical file is opened for expanding buffer I/O,
the size of the buffer begins at zero and expands as data is read into the
buffer as requested by the application. The minimum amount of the size expansion
is 256 KB. The buffer expands only if the requested data is contained within
a logical 256 KB page that is not yet contained in the buffer. For these reasons,
the amount of time it would take to read one byte of a 100 MB file opened
for expanding buffer I/O should be roughly identical to the time to read one
byte of a 50 KB file opened in the same manner.</p>
</div>
<div class="section"><strong>Situations in which expanding buffer I/O is useful</strong><div class="p">Expanding
buffer I/O should be considered as an option for improving the performance
of reads if any of the following conditions are met:<ul><li>The typical size of an optical file to be read is greater than 256 KB.</li>
<li>The amount of data read from the optical file between the open and close
stream file is a fraction of the total file data. The exact fraction would
be impossible to specify, but the performance improvements that are achieved
will be greater the smaller the fraction. For example, an application that
used expanding buffer I/O to read 25 KB of a 50 MB file would experience much
greater performance improvements than an application that read 45 MB of the
same file. An application that reads the entire 50 MB example file 40 KB at
a time through multiple reads probably would not experience any performance
improvement using expanding buffer I/O.</li>
<li>The application will not issue the Set Stream File Size, Lock-Unlock Byte
Range, or Write Stream file APIs while the file is open for expanding buffer
I/O. </li>
</ul>
</div>
<p>For specific details on how to implement expanding buffer I/O,
see <a href="specialattributes.htm">Using special attributes</a>.</p>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="tipsandtechniques.htm" title="The following techniques are often helpful in designing custom optical programs for your business.">Tips: Optical programming</a></div>
</div>
</div>
</body>
</html>