142
143
144
145
146
147
148
149
|
* ldap for auth (and maybe actors?)
* cdb (for static content, maybe? does this make sense?)
* mariadb/mysql
* the various nosql horrors, e.g. redis, mongo, and so on
parsav urgently needs an internationalization framework as well. right now everything is just hardcoded in english. yuck.
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
|
|
142
143
144
145
146
147
148
149
|
* ldap for auth (and maybe actors?)
* cdb (for static content, maybe? does this make sense?)
* mariadb/mysql
* the various nosql horrors, e.g. redis, mongo, and so on
parsav urgently needs an internationalization framework as well. right now everything is just hardcoded in english. yuck.
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.
|