Load RAG database in memory on use.

[blkt]

This change uses a trick to force the RAG database into memory by dumping the SQLite database from file to a temporary in-memory version of it using SQLite's backup function.

Based on percall statistic, this almost halves execution times.

With on-disk database.

 ncalls tottime percall cumtime percall filename:lineno(function)
911 0.017 0.000 47.983 0.053 .../src/codegate/storage/storage_engine.py:149(search)
911 41.336 0.045 41.336 0.045 {method 'execute' of 'sqlite3.Cursor' objects}
911 0.007 0.000 6.489 0.007 .../src/codegate/inference/inference_engine.py:90(embed)

With in-memory database.

ncalls tottime percall cumtime percall filename:lineno(function)
658 0.009 0.000 21.198 0.032 .../src/codegate/storage/storage_engine.py:147(search)
658 16.458 0.025 16.458 0.025 {method 'execute' of 'sqlite3.Cursor' objects}
658 0.004 0.000 4.638 0.007 .../src/codegate/inference/inference_engine.py:90(embed)

Also, added profiling to providers and search. Profiling can be activated exporting CODEGATE_PROFILE_<key> where <key> is the string passed to @profiled annotations. Profiling points are statically defined throughout the codebase.

[lukehinds]

Nice, taking a look at this, what is the memory footprint like?

[blkt]

I'm sorry @lukehinds I missed your comment.
Memory footprint is arund ~450 MB, and the database i ~200 MB itself, so it's still manageable on any developer's machine.

[lukehinds]

@blkt I am happy to get this merged, but do you think we need the profiler active still or does that add somehow?

[blkt]

The profiler is only active if CODEGATE_PROFILE_<key> is defined in the process environment, so it can be merged without impact to the end user.

The only change visible to the user is in speed.