[ros-bugs] [Bug 6693] New: Smarter DiskRead() for FreeLDR

ReactOS.Bugzilla at reactos.org ReactOS.Bugzilla at reactos.org
Sat Nov 26 15:29:16 UTC 2011


http://www.reactos.org/bugzilla/show_bug.cgi?id=6693

           Summary: Smarter DiskRead() for FreeLDR
           Product: ReactOS
           Version: TRUNK
          Platform: x86 Hardware
        OS/Version: ReactOS
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: Other
        AssignedTo: ros-bugs at reactos.org
        ReportedBy: carlo.bramix at libero.it
         QAContact: ros-bugs at reactos.org


Created an attachment (id=7043)
 --> (http://www.reactos.org/bugzilla/attachment.cgi?id=7043)
Fix for this bug

FreeLDR seems to take much time when it loads the files on my PC from CDROM or
from harddisk after installation.
I think this time is mainly spent with mode switches (when calling INT 13H) and
by the sync plus sector read time, these last two both included into INT 13H.
I'm also assuming that the time for copying data from transfer buffer is not so
important if compared with the others.
All this can be reduced greatly by making a bit more smarter implementation of
function DiskRead(), which actually just reads one sector each time: 2048 bytes
for ISO9660 filesystems on CDROMs and 512 bytes for all other media.
I would like to suggest a new implementation provided in the attached patch.
Since the transfer buffer is statically placed in the high portion of the
conventional memory (from 0x9000:0000 to 0x9000:8000) and allowing a maximum
size of 32 KByte, the new code fills that memory as much as it can.
So, the impact of mode switches and synces are reduced to 1/64 for harddisks
and 1/16 for CDROMs, leaving just the (now sequential) read time.
The pratical result on my real hardware: startup time decreased from 12 seconds
to just 3~4 seconds with my old harddisk.


-- 
Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.



More information about the Ros-bugs mailing list