How to write SDL code that performs badly

  1. Action:
    Have one function that returns everything.
    Example:
    Return the entire build environment (all bridges, tool binaries and library files, etc.) and all source files in a single composite value.
    Why is this slow?
    This will make the evaluator spend a lot of memory holding the value, CPU time manipulating it, and network bandwidth to/from the cache server. ?It will also ensure that any trivial change to any single aspect will blow the entire lot out of the cache, resulting in GAD (Glacially-slow Application Development) :) ?.

  2. Action:
    Have one function that takes everything as an argument.
    Example:
    Pass all source files in one big binding into one function that performs the entire build.
    Why is this slow?
    This will make its secondary dependency set huge, slowing down caching the function (both hits and misses).

  3. Action:
    If at all possible combine the two previous tactics. For maximum effect, pass a large value as a parameter to many different function calls, each of which modifies the value and returns the entire thing.
    Example:
    (TBD)
    Why is this slow?
    (TBD)

  4. Action:
    Evaluate everything as early as possible. (Why store a function as a value, when you can store it's result?) This can force uneccessary work in the beginning of an evaluation before anything useful happens. When done properly, it can also significantly increase the number of secondary dependencies.
    Example:
    (TBD)
    Why is this slow?
    (TBD)

  5. Action:
    Never mark any functions with /**nocache**/.
    Example:
    (TBD)
    Why is this slow?
    (TBD)

  6. Action:
    Never mark any function parameters with /**pk**/. Alternatively, mark every parameter with /**pk**/.
    Example:
    (TBD)
    Why is this slow?
    (TBD)

  7. Action:
    Avoid using models wherever possible. Do everything with user-defined functions. If you must use a bridge that insists on taking a function as a parameter be sure not to use a model. Also, use as many variables from the definition context as possible in the body of your user-defined functions.
    Example:
    (TBD)
    Why is this slow?
    (TBD)

  8. Action:
    When you must use models, try to do as little work as possible in them. If possible, just return variables from the files and import clauses. (Be sure to evaluate any imported models first.)
    Example:
    (TBD)
    Why is this slow?
    (TBD)

  9. Action:
    Do what the initial version of Adam's java bridge did: ?put the incoming sources into the bridge itself before evaluating, instead of passing them as args?
    Example:
    (TBD - copy/paste the example from the first java bridge)
    Why is this slow?
    Because it means that vesta records dependencies on things that aren't actually depended upon.