You are not logged in.

#101 2011-03-23 13:07:55

From: New York, USA
Registered: 2009-10-22
Posts: 4,109

Re: Pacman Optimization - Part 2

I don't see a reason to use this anymore with 3.5. fragmentation is dramatically reduced on the sync DBs, and the local DB was never all that painful to search on to begin with. I've heard too many stories involving this script and some unfortunate accidents that lead to useless databases as well.

This script certainly has stood the test of time, though.

Last edited by falconindy (2011-03-23 13:12:48)


#102 2011-03-23 13:51:22

Supreme Leader
From: Brisbane, AU
Registered: 2007-06-09
Posts: 10,653

Re: Pacman Optimization - Part 2

This is definitely not needed for the sync databases anymore.  The local database can still fragment, but not to the same extent as before due to having ~30% less files.  But given the relative number of packages in the local db to the sync dbs, this will be far less noticeable.  I doubt even pacman-optimize will be needed much anymore.


#103 2013-04-23 21:34:37

From: /usr/share/zoneinfo/Europe/FIN
Registered: 2009-07-17
Posts: 178

Re: Pacman Optimization - Part 2

It's a decade old thread, but the people with decade old HDDs still clearly need it:

swiftgeek wrote:

There is a difference for me and my 10 years old HDDs. Without cage 1st access can take >60s, with it's usually <10s.

luolimao wrote:

[...] yeah, it does help on my system (although the speed gains aren't THAT dramatic). It shrinks the time down by about 15s.

Though, they'd de better off just using the package.

PC: ASUS Maximus VIII Hero, Intel i7-6700K (4.6 GHz OC), NZXT Kraken X61, 16GB G.Skill DDR4-3200, MSI GTX 1080 Gaming X, Samsung 850 Pro 512GB, WD Black 6TB, Corsair Graphite 780T (Full Tower), be quiet! Dark Power Pro 11 650W (Platinum)
OS: Arch 64-bit / Windows 10 Pro 64-bit
Other: Dell UltraSharp 2560x1440 27", KB: Logitech G910, M: Logitech G502, HS: HyperX Cloud II, I: 100/10M


Board footer

Powered by FluxBB