פתרון מטמון וגישה ללא אגירה

בגרסה הרגילה אפשר להשתמש ב־buffer רגיל ובגדלים שמתאימים לממשק. בגרסה ללא buffering חייבים להתאים את כתובת ה־buffer, את offset ואת גודל הגישה לדרישות שנמדדו. שלוש התכונות שונות; כתובת מיושרת אינה מתקנת אורך לא מיושר.

ניסוי הכשל משנה את אורך הקריאה בלבד לערך קטן שאינו כפולה של היחידה הלוגית, ומשאיר את ה־buffer תקף. כך מבודדים את תנאי הבקשה בלי לכתוב לכתובת לא חוקית. לאחר הכשל שומרים GetLastError מיד ומחזירים את האורך לערך תקין.

השוואת מדידות

שתי הגרסאות צריכות לעבד את הנתונים שנקראו, למשל לחשב סכום בתים. אחרת אופטימיזציה או מדידה שמקיפה רק הקמה יכולות להשוות עבודות שונות. אם אחת כוללת פתיחת קובץ והשנייה משתמשת ב־handle שכבר פתוח, צריך לתקן את הניסוי או לתאר את ההבדל.

הרצה חוזרת יכולה ליהנות ממטמון מערכת או התקן, אבל אין להסיק מן הזמן לבדו איזו שכבה סיפקה את הנתונים. תיעוד סביבת ההרצה ו־trace מתאים עוזרים לצמצם את אי־הוודאות. אין צורך לשנות הגדרות cache כלל מערכתיות כדי להפיק ניסוי מועיל.

גבולות העמידות

הדגל ללא buffering אינו מסלק בהכרח אגירה בחומרה או בשכבת אחסון מרוחקת. השלמת כתיבה והבטחה שהמידע ישרוד כשל חשמל אינם אותו משפט. נדרשים חוזה flush ותצורה שמכבדת אותו, וכן פורמט שמסוגל לזהות כתיבה חלקית ולהתאושש ממנה.

יצירת view מקצה מרחב כתובות ומקשרת אותו לקובץ, אבל לא בהכרח מביאה את כל הדפים לזיכרון. לכן השעון צריך להקיף גם את מעבר הקריאה על הנתונים. מספר faults וזמן המעבר יכולים להשתנות בין גישות ראשונות וחוזרות, בעוד זמן יצירת המיפוי כמעט לא משתנה.

הבחירה הסופית צריכה להישען על תוצאה שחוזרת בתנאים המתועדים ועל מורכבות שניתן לתחזק. אם המסלול המיושר אינו משפר את העומס הרלוונטי, אין יתרון הנדסי בעצם השימוש בדגל.