|author||Eric Wong <firstname.lastname@example.org>||2019-09-21 00:06:42 +0000|
|committer||Eric Wong <email@example.com>||2019-09-22 03:07:58 +0000|
Inline::C seems alright, so we might use it more since it still allows end users to quickly make changes. Our performance on rotational disks is also terrible, and could be improved...
2 files changed, 5 insertions, 6 deletions
@@ -40,7 +40,8 @@ the shiny new.
Avoid relying on compiled modules too much. Even if it is Free,
compiled code makes packages more expensive to audit, build,
distribute and verify. public-inbox itself will only be implemented
-in scripting languages (currently Perl 5).
+in scripting languages (currently Perl 5) and optional JIT-compiled C
Performance should be reasonably good for server administrators, too,
and we will sacrifice features to achieve predictable performance.
@@ -5,7 +5,7 @@ performance, ease-of-setup, installation, maintainability, etc
all need to be considered for everything we introduce)
* general performance improvements, but without relying on
- XS or compiled code any more than we currently do.
+ XS or pre-built modules any more than we currently do.
* mailmap support (same as git) for remapping expired email addresses
@@ -101,10 +101,8 @@ all need to be considered for everything we introduce)
* imperfect scraper importers for obfuscated list archives
(e.g. obfuscated Mailman stuff, Google Groups, etc...)
-* support hooks, since low-level git-fast-import does not run them
- (note: may not be needed since we do grokmirror manifest.js.gz, now)
* consider using HTTP::Date instead of Date::Parse, since we need the
former is capable of parsing RFC822-ish dates, used by Plack, and
the latter is missing from OpenBSD and maybe other distros.
+* improve performance and avoid head-of-line blocking on slow storage