parsav  Diff

Differences From Artifact [23851a52a8]:

• File parsav.md — part of check-in [0d10a378e9] at 2021-01-11 01:53:23 on branch trunk — add auth docs and rsa auth (user: lexi, size: 18792) [annotate] [blame] [check-ins using]

To Artifact [d83ecc5b3e]:

• File parsav.md — part of check-in [03ea3dffe7] at 2021-01-14 01:11:51 on branch trunk — more work on UI and circles (user: lexi, size: 19042) [annotate] [blame] [check-ins using]

   142    142   * ldap for auth (and maybe actors?)
   143    143   * cdb (for static content, maybe? does this make sense?)
   144    144   * mariadb/mysql
   145    145   * the various nosql horrors, e.g. redis, mongo, and so on
   146    146   
   147    147   parsav urgently needs an internationalization framework as well. right now everything is just hardcoded in english. yuck.
   148    148   
   149         -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
          149  +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 can 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, and much of the UI code has been converted; the database code will also need to be converted, however, and this will be too time-consuming to be worth tackling any time soon. new functions should be written to use the memory pooling strategy, however.