I did some experiments on putting daase into memory instead of disk.
For the 8.5MB interp.daase, load it into memory takes 23MB:
(sb-ext:gc)
(room) ;; Dynamic space usage is: 19,602,224 bytes.
(setq l1 '())
(with-open-file (s "interp.daase")
(do ((item (read s nil 'eof) (read s nil 'eof)))
((eq item 'eof))
(setq l1 (cons item l1))))
(sb-ext:gc)
(room) ;; Dynamic space usage is: 42,911,520 bytes.
The number is reasonable: viewing l1 as a tree, it has 1.4 million
leaves (which are symbol or number), and requires 1.4 million cons
cells, and each takes a machine word -- 64 bits so:
1.4 million x 2 x 8 bytes = 22.4 MB
Of course, if we want all of database in memory, why not put
it directly in the various hash tables? I have not tested how
much memory this would require, should be much less than 23 MB.
Bzip2 compress interp.daase gives 504K, that's also reasonable
considering there's so much duplicated sub-expressions in it.
So I wonder does in memory daase (then dump to disk image) have
advantages over current external text daase?
Or consider a crazier thing: load everything into memory (image)
and distribute FriCAS as a single executable! It actually can
be a good idea for Windows.
A rough test using fricas0 shows that loading the 1383 algebra
fasl files (39MB) into memory takes 26MB RAM, interp/ takes 13MB.
- Qian
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/2e092244-2c7a-4f8c-b16b-d60c78c686fd%40gmail.com.
