On 5/10/26 8:31 PM, Waldek Hebisch wrote: > > Well, currently in 'kernelEnterInCache' we first try binary > search. AFAICS this handles majority of calls. Only when > this fails we do linear search. Doing linear search > always is likely to slow down things. It is not clear to > me if smaller cache is enough to compensate this. > Yes, for new kernels, both methods need to linear search all cache. For existing kernels, current method is much faster.
A benchmark: src/input/mapleok.input, contains 248 integrals. Current time: 13.94s ; hashtable: 13.39s. Number of kernel cache drops from 4876 to 355. ")trace SCACHE )timer )nt" shows that over 8 seconds is spent in SCACHE, is that accurate?! For even longer sessions, hashtable method may have advantage. But we can have the best of both worlds: when the array cache needs to expand (or hitting some threshold, or triggered manually), use sb-ext:make-weak-pointer on the kernels, do a GC, create the smaller cache again. I'll report back. - 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/6a985899-1f1f-4398-8e6b-bcd73298d10c%40gmail.com.
