| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Reduce the number of allocations we make, so there's less
pressure on the allocator and less overhead to keep track
of the allocations in.
|
| |
|
|
|
| |
It didn't save us any lines of code nor did it do anything
useful since we would overwrite everything anyways.
|
| |
|
|
|
|
| |
Any pruned files will be noticed during update and pruned
from the live database, so this inefficient function can
go away and never come back.
|
| |
|
|
|
|
| |
Pruning is very expensive and we won't need it in the future
anyways. This brings startup back to previous speeds (before
songvec changes).
|
| |
|
|
|
|
|
| |
Our linked-list implementation is wasteful and the
SongList isn't modified enough to benefit from being a linked
list. So use a more compact array of song pointers which
saves ~200K on a library with ~9K songs (on x86-32).
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently, when the tag cache is being serialized to hard disk, the
stdio buffer is flushed before every song, because tag_print.c
performs unbuffered writes on the raw file descriptor. Unfortunately,
the fdprintf() API allows buffered I/O only for a client connection by
looking up the client pointer owning the file descriptor - for stdio,
this is not possible. To re-enable proper stdio buffering, we have to
duplicate the tag_print.c code without fprintf() instead of our custom
fdprintf() hack. Add this duplicated code to tag_save.c.
|
|
|
Move everything which dumps song information (via tag_print.c) to a
separate source file. song_print.c gets code which writes song data
to the client; song_save.c is responsible for serializing songs from
the tag cache.
|
