[Android Apps and Games] Dark3n:
[MENTION=4969607]MrTooPhone[/MENTION]

The later one, can not deal with them. It always happened, just now that SD Maid is honest about it and shows more accurate results for each database.

(though reading bad ratings due to SD Maid now "failing" on databases, I regret it a bit)

[MENTION=5119654]IronTechmonkey[/MENTION]

It's expected, but difficult to explain as there is not one single change causing this, but multiple hundred changes that trade a bit more speed for an extra test or check.

I can give you a few examples though.

A common slowdown in almost all tools can be attributed to the support of regular expressions. This was not supported at all in v3.

v4 supports these now both in default definition, as well as in database definitions, SystemCleaner filters and exclusions.

The UserFilter in the SystemCleaner support this, but don't have a UI for that yet. You can create create a filter file via hand though and then import it.

Here is an example I did that deletes WhatsApp Sent files:

https://drive.google.com/open?id=0BwoXRNB2W15rUG5sbVZMTHRWNkE

{
"version": 4,
"label": "WhatsApp Sent Files",
"description": "Pics, Videos and other sent files from \/sdcard\/WhatsApp\/Media",
"identifier": "c6dfd0ff00e4.scuf.sdm",
"color": "#43d854",
"rootOnly": false,
"targetType": "FILE",
"pathContains": [
"\/WhatsApp\/Media\/WhatsApp"
],
"regexes": [
"^(?:[\\W\\w]+?)(?>WhatsApp/Media/WhatsApp Video/Sent/)(?:[\\W\\w]+?)$",
"^(?:[\\W\\w]+?)(?>WhatsApp/Media/WhatsApp Images/Sent/)(?:[\\W\\w]+?)$",
"^(?:[\\W\\w]+?)(?>WhatsApp/Media/WhatsApp Documents)/Sent/(?:[\\W\\w]+?)$"
],
"locations": [
"SDCARD"
],
"exclusions": [
".nomedia"
]
}

See the section "regexes".

I have to write documentation on this but I'm still bugfixing various things (ugh MediaTek devices... :p).

The same is now also supported for exclusions, if you select "show default" from it's options you can see the predefined regex exclusion that SD Maid uses to exclude itself.

(You can actually create regex exclusion from the UI already, just make sure it starts with "regex:" like the examples.)

Btw http://regex101.com/ is awesome to test regexes.

So all this regexing just costs more time.

Another example in the CorpseFinder would be nested directories.

Imagine a directory setup like this:

"/sdcard/Corpse1/DirInUse/Corpse2"

So the perfect solution would be to not delete "Corpse1", because of "DirInUse", but delete "Corpse2".

This checking of cascaded corpses is quite laborious. In V3 this was a bit unreliable, usually causing only Corpse1 to be excluded.

In v4 this should now work correctly up to 3 nesting levels (more is possible but costs more time). I might make this configure via settings.

To eliviate issues with different nesting levels and the fact that different locations on the same "storage" have to be treated differently, V4 now works all operations based on LOCATION types, this means that /sdcard/ is a location and /sdcard/Android/data would be another location. You can actually see all detected locations in the debug log during initialisation.

Another example based on this would the new support for LOCATION types as filter criteria. Because filter can now be exported and shared among users, just hardcoding something like "/storage/emulated/0" would break pretty easily, so to make this generalised you can specify locations instead of paths. See "locations" in the definition above. This of course also allowed me to make the default filters more precise as it did not have to be based on matching a specific path. Doing "determineLocation(...)" for each file costs time again, though SD Maid already tests the cheap criteria first before doing more expensive tests.

There is some speed possible here when I find time for some micro optimizations.

Database tool is slower because it scans more (lots more), due to no longer being restricted to ".db" files (https://github.com/d4rken/sdmaid-public/issues/182). This causes us to scan lots more files. To then know if each found file that matches the base criteria is really an SQL DB, we then have to do a test to check the actual database type (e.g. pragma version).

Because we there were always problems with some apps and databases there are now also additional checks regarding the owning apps.

By default databases of running apps are skipped, but If you turn that option off, SD Maid actually suspends the app in place through linux process management and then resumes it afterwards.

This is only a few of the changes, but I hope this gives you some idea why some slow down is expected (and why V4 took so long to develop).

Sometimes this all seems insane when I could just delete the default caches blazingly fast and display "PHONE BOOSTED" in bright red letters to rake in lots of cash ;).