On Fri, 28.06.13 17:26, Jan Janssen ([email protected]) wrote: > Unfortunately, order of sd_journal_enumerate_unique() is > undefined, so we have to sort the boot IDs. For that we > seach for any log entry with a specific boot ID and then > use the realtime stamp to order everything. > --- > > Hi, > > I redid the boot ID look up to use enumerate_unique. > > This is quite fast if the cache is warm but painfully slow if > it isn't. It has a slight chance of returning the wrong order if > realtime clock jumps around. > > This one has to do n searches for every boot ID there is plus > a sort, so it depends heavily on cache hotness. This is in contrast > to the other way of look-up through filtering by a MESSAGE_ID, > which only needs about 1 seek + whatever amount of relative IDs > you want to walk. > > I also have a linked-list + (in-place) mergesort version of this > patch, which has pretty much the same runtime. But since this one > is using libc sorting and armortized allocation, I prefer this > one. > > To summarize: The MESSAGE_ID way is a *lot* faster but can be > incomplete due to rotation, while the enumerate+sort will find > every boot ID out there but will be painfully slow for large > journals and cold caches. > > You choose :P
Applied this one now. If people start complaining about its speed we can reinvestigate and do find some way for optimization... Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
