| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
- We'll need these to eliminate the remaining direct accesses to
N, EVR (and Flags) on random access patterns such as rpmdsSearch().
|
|
- Eliminate numerous repeated direct accesses to [o]ds N, EVR and Flags,
instead grab them into local variables through getter functions as
needed: on entry for ods which doesn't change, for ds in the loop
as we're changing ds->i here.
|
|
- The EVR comparison is a distinct operation of its own: rpmdsCompare()
looks at the other properties, EVR comparison is done if needed.
Doesn't affect speed or functionality, but cuts down on the
big number of local variables and has the nice side-effect of
making the xstrdup() allocations local within rpmdsCompareEVR()
|
|
|
|
- Eliminate numerous repeated direct accesses to ds N, EVR and Flags,
instead grab them into local variables through getter functions
as they are needed. Besides making it easier on the eyes, makes the
function safe(r) wrt illegal iterator values etc.
|
|
- Eliminate numerous repeated direct accesses to ds N, EVR and Flags,
instead grab them into local variables at entry. This also makes
the function safe illegal iterator values (ie calling when iteration
not started), previously the bounds were not checked.
|
|
- String pool offset resize was off by one, oops
- String pool data-area resize requires rehashing all the strings,
as the key pointers change. Ouch. Should be avoidable by extending
rpmhash to allow passing the pool itself around in comparisons as "self"
and using offsets as keys, but for now working counts more than speed.
- The unfreeze-sizehint calculation could be negative. Turn the initial
size into constant and use that as a minimum, otherwise rehashing
uses (more or less arbitrary) heuristics to come up with some number.
Lots of fine-tuning ahead...
|
|
- Always push base and dir names into file info sets string pool,
whether private or shared. For basenames, this can save significant
space even in a private pool, for dirnames private pool is moot
as the names are already unique, shared pool is quite another story.
- Adjust fpLookupList() to take a pool and id's as arguments.
- This introduces a fair amount of overhead, so things will be somewhat
slower until the transition to pool id's is (more) complete. Sometimes
things have to get worse before they get better... Other than that,
this should be entirely invisible to callers.
|
|
- Grab and validate the file triplet before placing the data into the
file set. Other than making it more explicit, doesn't matter right
now but we'll need this shortly.
- Refactor the file triplet sanity check into a generic indexed triplet
sanity check (and notice there was an error in the previous index
range checking, duh)
- Apart from the index range fix, shouldn't change any actual functionality
|
|
|
|
- Just for consistency's sake: now the "core" file triplet data does
not depend on how we got called.
|
|
- Split file info generation by mandatory/optional data: every file info
set has the file triplet information, but all other data is optional
depending on the create flags. No functional changes.
- Being able to create just the core file triplet and fully populate
later might be useful for checkInstalledFiles(), but we'll see about
that...
|
|
- For filename triplets we'll need to get and validate the data
before inserting into the pool, so we'll need this shortly.
|
|
- rpmfiNewPool() allows specifying shared/private pool, and
rpmfiNew() is now just a wrapper to always call it with a private pool.
|
|
- I suspect these will be used widely, to avoid having to include
rpmstrpool.h all over in headers...
|
|
|
|
- Removes the last use of our former simple, stupid and slow caches
- For now, use a per-fi pool for this just like the previous caching
did. Memory use is slightly increased but its faster than before,
to reap the full benefits (memory and otherwise) we'll want a
per-transaction pool for these, to be added later.
|
|
- With the string pool we dont have to worry about overflowing the
indexes so we can lump all this relatively static data into one pool.
Because rpmsid's are larger than the previous cache indexes, we'll
loose some of the memory savings, but then the pool is faster on
insertion, and we'll only need one of them so...
- The misc. pool is never freed, flushed or frozen so it'll "waste" memory
throughout the lifetime of a process (similarly to the previous caches)
but its not huge so .. ignoring that for now.
|
|
- Very few packages have RPMTAG_FILECAPS at all, and the memory saving
for those that do is so marginal it hardly matters at all. At least
for now, dont bother.
|
|
- The pool stores "arbitrary" number of strings in a space-efficient
manner, with near constant (hashed) string -> id lookup/store and
constant time id -> string and id -> string length lookups.
- Credits for the idea go to the Suse developers working on libsolv,
the basic concept is directly lifted from there but details
differ due to using rpm's own hash table implementation etc.
Another minor difference is using size_t for offsets to permit over
4GB total data size on 64bit systems, the total number of id's in
the pool is limited to uint32 max however (like in libsolv).
- Any (re)implementation bugs by yours truly, this is almost certainly
going to need further tuning and tweaking, API and otherwise.
|
|
|
|
- Returning structs by value is a bit icky, pass in a fp pointer
for fpLookup() to fill in instead. This leaves the actual return code
free for handling errors (but ignoring that for now as we always have)
The other option would be always mallocing the return, and we dont
want to do that...
- Shouldn't change any actual functionality.
|
|
- While harmless, having to count on one and act on another iteration
gets expensive when there are lots of labels specified. Especially
as the iterator initialization can already load the same headers
multiple times, sigh...
|
|
- Partial NEVRA labels cannot be reliably parsed, the various combinations
need to be figured out by trial-and-error. The rpmts layer doesn't stand
a chance of getting it right so move it to rpmdb layer. This doesn't
make the process any less stupid, but at least we get correct results...
- Fixes iterator count when arch is used in a label and more than one
arch variants of a package are installed. Previously iterator count
could be more than one despite actual iteration only hitting one
match, as the arch RE match was added after already initializing
the iterator.
- Also fixes various pathological cases:
- If a legal arch was part of name, version or release (stupid but legal)
we misinterpreted it for arch and failed to find the package.
- If a package with unknown architecture was installed (with --ignorearch)
we could not remove it by its arch as we relied on rpmIsKnownArch()
|
|
- Missed opportunity in commit 1a3a4089def9b00790eeebd6f931c99a03a3d44b:
removed packages have already gotten fingerprinted so there's no need
to redo that here.
|
|
- This is a false positive really, or at least a cant-happen case
|
|
- Another modest improvement in redundant rehashing elimination, but in the
big picture, this is really just another fart in the Sahara desert...
|
|
- Speedup depends on transaction and yadda yadda, on my large erasure
transaction testcase this is circa two percent saving on rstrhash()
total costs.
|
|
|
|
- Speedup depends on the transaction and is likely to be rather modest
anyway, but can't hurt either...
|
|
- Speedup depends on the transaction and is by no means enormous,
but on my testcase of a largish erasure transaction this shaves
off circa four percent of the cycles spent in (re)hashing the
basenames.
|
|
- In cases where more than one operation is done with the same key, these
can be used to avoid the relatively expensive rehashing of the key.
|
|
|
|
- Avoid calculating string lengths if versions are equal
- Avoid calculating string lengths twice in numeric comparison
|
|
- Check for lowercase letters before uppercase. A very minor difference
as such, but our file digests use lowercase hex and this gets
called a lot from rpmfiNew().
|
|
- We've been calling matchNetsharedpath() for every single file in
the transaction regardless of whether %{_netsharedpath} is set or
not (and almost always it is not), meaning lots of pointless
strlen() calls and in case of erasure, rpmfi iterations performed.
Not exactly a massive speedup but a speedup nevertheless.
|
|
- Avoid repeatedly calling rpmteGetFileStates() for every file processed
- Avoid rpmfi iteration, use a good ole for-loop and index-accessors
- Dont bother looking up symlinks for skipped files
- Eliminate rpmfi from the latter loop, its not used for anything there
- Not that this is going to show on wall-clock times, the cycles saved here
are going to get very much lost in the noise of more expensive things.
|
|
- If the replacing %config file is a %ghost, then we'll just leave whatever
might be on disk alone.
- OTOH in the opposite case we probably *should* take backups, if the
file exists on disk and is differs from the new non-ghost (but
currently we take never take backups for %ghosts)
|
|
- This can happen on %ghost files, fsm->ossufix is never set for them.
Arguably this is a bug in the file disposition calculations but for now...
|
|
- Similar to commit 80ee39da35544253cab12abd54af8754335ac945: this
started leaking at commit 3f996a588a56141df146c33583a13c0542323977
as rpmfiFNIndex() returns malloced memory. Refactor the lucky 13
return points into one, allowing cleanup at exit.
|
|
- Previously we'd turn all but FAILED results into "OK" after first
check, now we return the real value. And perhaps more importantly,
no longer try re-verifying previously failed headers in vain.
|
|
- When we get rpmdb hits on files from packages that are to be removed
in the same transaction, we can use its existing file info set
to grab base- and directory names to avoid bunch of headerGet()'s
and consecutive rpmtd manipulation. In theory this should speed up
transactions where lots of packages get removed, in practise not
really - the big cost here is in loading the headers from db in the
first place, despite not being really needed.
|
|
- When we get rpmdb hits on files from packages that are to be removed
in the same transaction, we can use the exisiting file info set
to avoid constructing a new temporary one. Might be measurable
in large updates.
|
|
- Change the hashtype name to something else, its no longer a plain
int hash. Still needs double definition as its not contained in
a single source (might want a wrapper similar to rpmal), but
slightly more contained now than the previous intHash definition.
- This opens up some new possibilities, to be taken advantage of
in later commits.
|
|
- This is really private to rpmdb.c (other than being exposed in
the struct definition in backend/dbi.h, sigh), let it live its
own life there.
- No functional changes here, just cleaning up a bit for next steps.
OTOH we could now cache the actual result, not just success... but
leaving that to another time.
|
|
|
|
- The cases in handleOverlappedFiles() and handleInstInstalledFile() only
differ by presence of "other file state", unify the copy-paste code
to helper function and comment a bit more.
- Push all the color fiddling into the helper, eliminating loads of
unnecessary rpmfiFColorIndex() calls in the common case. Also gives
us a single point of control for the color-conflict behavior.
- This is not supposed to change any behavior at all, just refactoring...
|
|
- Just use the file action to determine if we already decided something
for this file or not, no need for additional helper trackers.
|
|
- Kinda similar to commit 12322bad67b809101017a3991e67d09a2af4803c but for
conflicts among the added set: grab the conflict filtering flag once
outside the loop and use to determine whether to report detected
conflicts or not. Doesn't change actual functionality.
|
|
- Also test for the cases where packages are installed in different
transactions, the outcome should be exactly the same in every case
regardless of the order.
- Change the expected output to something slightly more readable for
us humans
|
