Self Optimizing Code
crimaniak via Digitalmars-d
digitalmars-d at puremagic.com
Thu Aug 4 04:35:41 PDT 2016
On Tuesday, 2 August 2016 at 22:06:38 UTC, Mark "J" Twain wrote:
> Instead, a better solution would be to use variables:
>
> if (n*length > m*capacity) expand(l*length)
Some time ago I played with self-optimizing cache layer.
Problem: Time to obtain cache items is unknown and server
dependant. For example, network can be involved in this.
Sometimes is it localhost, sometimes server on another continent.
Time to cache it is unknown too. For example if memcached
extension is not installed on this server then fallback to disk
backend will slow cache performance very much. So we don't know
is it worst to cache.
Solution: cache measures own performance and acts accordingly.
So I make next things:
1. Functional interface instead of save/load type interface.
cacheLevel.get(functor_to_get_item) allow to measure item
obtaining time.
2. Implement all measuring/controlling logic in separate class
with interface AbstractStatist, in CacheLevel class make just
hooks for it. So changing AbstractStatist implementation I can
change work mode to measure statistics and use it or work as
usual cache (EmptyStatist for all empty hooks). I make
implementation to skip all items not worst caching
(calcTime/calcHits*totalHits-totalTime < 0) but it's possible to
make more smart things (like caching only most efficient items
not exceeding cache size).
In my experience I can draw some conclusions.
1. It need to separate measure mode and control mode. You can't
have accurate statistics while changing system behavior according
to current statistics state.
2. Statistics can be different for different applications but for
specific application in specific conditions for most cases it can
be approximated as constant.
So for array allocating strategy more realistic scenario the
next, I think:
1. Application compiled in some 'array_debug' mode then some
statist trait added to array, collect usage statistics and writes
optimal constants at the application exit.
2. Programmer configure array allocator in application according
to these constants.
3. Application builds in release mode with optimal allocation
strategy and without any statist overhead and works fast. Users
are happy.
More information about the Digitalmars-d
mailing list