| 1 |
On Mon, Dec 31, 2012 at 11:13 PM, Maxim Kammerer <mk@×××.su> wrote: |
| 2 |
> On Tue, Jan 1, 2013 at 2:10 AM, Alec Warner <antarus@g.o> wrote: |
| 3 |
>> flatfile lookups are 2-4ms with hot cache. How much faster is the db |
| 4 |
>> option? |
| 5 |
> |
| 6 |
> I guess it depends on the implementation and how close is the system's |
| 7 |
> operational situation to an ideal one (whether swap started thrashing, |
| 8 |
> etc.). A DB is the proper solution that can be improved if necessary |
| 9 |
> (e.g., keeping often-used parts in RAM). Filesystem where it resides |
| 10 |
> can be offered hardware with lower seek time or better cache. But I |
| 11 |
> agree that it is easy to rationalize bad solutions. I don't like |
| 12 |
> waiting on an "ls -l" in addition to the system not being responsive |
| 13 |
> due to some other reason, though. But maybe I am expecting too much, |
| 14 |
> with even PolKit delegating each query to a full-blown Javascript |
| 15 |
> library nowadays. |
| 16 |
> |
| 17 |
|
| 18 |
You realize that files are cached in RAM right? There's a page cache |
| 19 |
and pages are ejected when the system needs that RAM for something |
| 20 |
else and they're ejected in an LRU fashion. More than likely those |
| 21 |
pages are always in cache. I say pages very liberally here because |
| 22 |
most of the files we're dealing with are less than 4096 bytes (yep, |
| 23 |
I'm making that assumption) so its really 1 page per file. The result |
| 24 |
is that the request for the data (assuming mmap here) is handled by |
| 25 |
just doing a bounds/range check and converting the virtual address to |
| 26 |
the physical address the data is wired in. The time required to parse |
| 27 |
the average GNOME single user desktop machine (I've got 44 users and |
| 28 |
69 groups on that box) is likely smaller than the overhead of a DB. |
| 29 |
|
| 30 |
-- |
| 31 |
Doug Goldstein |
Archives