Skip to content

Commit 5022ac2

Browse files
committed
Add a paragraph about WASM file size
1 parent fe52a4d commit 5022ac2

File tree

1 file changed

+13
-5
lines changed

1 file changed

+13
-5
lines changed

content/articles/reranking-on-the-client-side.md

+13-5
Original file line numberDiff line numberDiff line change
@@ -97,11 +97,19 @@ disaster. But I can build small bits in Rust, especially if I have
9797
already built them in Python. So over the last few days, I've [rebuilt
9898
our heuristic ranking in Rust](https://github.com/mwmbl/rankeval/).
9999
The rust compiles to web assembly which will eventually be called from
100-
our [excellent new front end](https://alpha.mwmbl.org/). Now all the
101-
back end needs to do is pull out pre-ranked results for each unigram
102-
and bigram. These can be easily cached, and potentially even kept in
103-
cloud storage. If we are ever going to serve millions of users on our
104-
shoe-string budget, then this is how we will have to do it.
100+
our [excellent new front end](https://alpha.mwmbl.org/). The WASM file
101+
is currently 1.3M with optimizations turned on, which is larger than
102+
I'd like. Gzipped it is 491K which doesn't seem too bad. And the
103+
client only needs to load it once, until we change our ranking
104+
algorithm.
105+
106+
It is likely that we will still need to do some ranking on the server
107+
side, for low-powered devices, and possibly API clients. But with
108+
client-side ranking, all the back end needs to do is pull out
109+
pre-ranked results for each unigram and bigram. These can be easily
110+
cached, and potentially even kept in cloud storage. If we are ever
111+
going to serve millions of users on our shoe-string budget, then this
112+
is how we will have to do it.
105113

106114
If you would like to get involved, join us on our
107115
[Matrix server](https://matrix.to/#/#mwmbl:matrix.org), or send a pull

0 commit comments

Comments
 (0)