• src/doors/syncduke/Engine/src/filesystem.c

    From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Friday, June 26, 2026 22:40:09
    https://gitlab.synchro.net/main/sbbs/-/commit/a22754e15f142c3c002c4767
    Modified Files:
    src/doors/syncduke/Engine/src/filesystem.c
    Log Message:
    syncduke: load the GRP into RAM so lump reads don't round-trip over SMB

    The Build engine read each GRP lump via unbuffered 2-4 byte read()s (kread16/32/8 -> kread -> lseek+read), relying on the OS file cache to make them cheap. That holds on local disk but not over a network share: on an SMB-mounted install every tiny read round-trips to the file server, so door startup (CON compile, art/palette load) took ~13.7s vs ~3.2s on local disk.

    Slurp the read-only GRP into RAM once at initgroupfile() (folding in the existing CRC32 pass) and serve each lump kread() via memcpy; fall back to the fd path if the allocation fails. The original authors clearly intended this (the commented-out groupfil_memory malloc and the "caches the GRP in memory" note). SMB startup now matches local disk (~3.2s); local is unchanged.

    Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sunday, July 05, 2026 03:53:27
    https://gitlab.synchro.net/main/sbbs/-/commit/70a6778ad0784b8d5dca5fee
    Modified Files:
    src/doors/syncduke/Engine/src/filesystem.c
    Log Message:
    syncduke: slurp kopen4load() filesystem files into RAM (user-map load)

    Loading a third-party user map over a no-oplock SMB share took minutes: loadboard() reads the .map one 1-4 byte field at a time (~211k kread()
    calls for Roch.map's 1023 sectors / 8027 walls / 2251 sprites), and for
    a SYSTEM_FILE each kread() was an unbuffered read() syscall -- a full
    network round trip when client-side caching is disabled (no
    oplocks/leases), so the door sat "frozen" on the ENTERING USER MAP
    screen for a couple of minutes.

    Apply the same cure initgroupfile() already applies to GRPs: slurp the (read-only) file into RAM at kopen4load() time -- capped at 16MB -- and
    serve kread/klseek/kfilelength from the buffer; fall back to the fd
    path when the file is over-cap or the slurp fails. Stock levels never
    hit this (they live inside the in-RAM GRP); only -map user maps read
    via the filesystem. Measured: Roch.map cold start went from 2-3
    minutes to 3.7 seconds (~211k read syscalls down to 7).

    Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net