parsav  Diff

Differences From Artifact [1e18c01a8c]:

• File parsav.md — part of check-in [8d35307a7f] at 2021-01-10 03:54:46 on branch trunk — add memory pool impl, handle various little details, add beginnings of mimelib (user: lexi, size: 17508) [annotate] [blame] [check-ins using]

To Artifact [af14d66fc5]:

• File parsav.md — part of check-in [00a6815988] at 2021-01-10 11:17:29 on branch trunk — add follow notices (user: lexi, size: 17544) [annotate] [blame] [check-ins using]

   135    135   * ldap for auth (and maybe actors?)
   136    136   * cdb (for static content, maybe? does this make sense?)
   137    137   * mariadb/mysql
   138    138   * the various nosql horrors, e.g. redis, mongo, and so on
   139    139   
   140    140   parsav urgently needs an internationalization framework as well. right now everything is just hardcoded in english. yuck.
   141    141   
   142         -parsav could be significantly improved by adjusting its memory management strategy. instead of allocating everything with lib.mem.heapa (which currently maps to malloc on all platforms), we should allocate a static buffer for the server overlord object which can simply be cleared and re-used for each http request, and enlarged with `realloc` when necessary. the entire region could be `mlock`ed for better performance, and it would no longer be necessary to track and free memory, as the entire buffer would simply be discarded after use (similar to PHP's original memory management strategy). this would remove possibly the largest source of latency in the codebase, as `parsav` is regrettably quite heavy on malloc, performing numerous allocations for each page rendered.
          142  +parsav could be significantly improved by adjusting its memory management strategy. instead of allocating everything with lib.mem.heapa (which currently maps to malloc on all platforms), we should allocate a static buffer for the server overlord object which can simply be cleared and re-used for each http request, and enlarged with `realloc` when necessary. the entire region could be `mlock`ed for better performance, and it would no longer be necessary to track and free memory, as the entire buffer would simply be discarded after use (similar to PHP's original memory management strategy). this would remove possibly the largest source of latency in the codebase, as `parsav` is regrettably quite heavy on malloc, performing numerous allocations for each page rendered. **update:** this is now in progress