Pretend "caching" implementations?

  • F

    I'm kind of used to writing backend code which process a lot of data, I'd then call the same functions to access that data repeatedly but without the overhead of actually rebuilding it. I'm sure it's a familiar pattern to a lot of programmers, e.g.;

     * Do our heavyweight functionality.
     * @param bool rebuild
     *   Set to true to force the cache to be updated.
    function doAThing(rebuild = false)
      data = cacheGet("doAThing")
      // If there is no data in the cache then do our "heavy" thing.
      if !data or rebuild then
        // Do ittttt........
        data = []
        for i = 0 to len(hugeThing) loop
          data[i] = crunch(...)
        // "doAThing" is the label for retrieval so
        // several things can be set or retrieved.
        cacheSet("doAThing", data)
    return data

    And when the data itself has something additionally added to it, then you'd force a rebuild. Obviously there are ways to do this already by making a globally accessible array but they're not especially "clean". Maybe this type of programming just suits me as I'm primarily a backend developer! ;)

    Anyways ... my thoughts currently are, this would be good for;

    • Parsing layout/ maze/ room data
    • Parsing image (uploadImage) data, where it's created from a non-native means (in my case, from ZX Spectrum data)
    • Okay basically anywhere when you need to parse large sets of data...

    I guess even, for some things using the file save/load for the "cache" might be desirable? It depends really on how much processing happens.

    Just wondering if anyone had any thoughts on implementation? I found myself doing something similar to create a room/ maze buffer for my games but it's rather specific to the task.

Log in to reply