Apparently `normalizer_normalize` is not verifying itself whether the string needs to be converted or not. Or does it at least not very performantly.
This simple change leads to a 4% performance gain on the processing of normalizeUnicode. Since this method is called quite often (i.e. for every file path) this has actually a measurable impact. For examples searches are now 200ms faster on my machine. Still not perfect but way to go.
Part of https://github.com/owncloud/core/issues/13221
Isset is a native language construct and thus A LOT faster than using strlen()
On my local machine this leads to a 1s performance gain for about 1 million paths. Considering that this function will be called a lot for every file operation this makes a noticable difference.
`normalizePath` is a rather expensive operation and called multiple times for a single path for every file related operation.
In my development installation with about 9GB of data and 60k files this leads to a performance boost of 24% - in seconds that are 1.86s (!) - for simple searches. With more files the impact will be even more noticeable. Obviously this affects every operation that has in any regard something to do with using OC\Files\Filesystem.
Part of https://github.com/owncloud/core/issues/13221
We already use `.text()` here which automatically properly encodes the string. Thus the string will be double-encoded and look ugly. (i.e. when you search for ">" you will see "No results found for >")
Fixes itself.
The check for invalid paths is actually over-complicated and performed twice resulting in a performance penalty. Additionally, I decided to add unit-tests to that function.
Part of https://github.com/owncloud/core/issues/13221
Otherwise every time the AppStore was opened a lot of connections to the AppStore server were made which resulted in a terrible performance.
This changeset will cache the response for a sensible time so that only the first request will be somewhat slow.
Performance changes:
- Loading a category took previously more than 3 seconds on my machine. Now for every follow-up request it takes less than 200ms, resulting in a performance gain of 1950%
- Loading the category list took previously about 750ms - now it takes 154ms, a total performance gain of 395%
Otherwise a fatal PHP error is thrown since the filesystem is not setup:
```
( ! ) Fatal error: Call to a member function getOwner() on null in /Users/lreschke/Programming/core/lib/private/files/filesystem.php on line 817
Call Stack
1 0.0004 247792 {main}( ) ../index.php:0
2 0.0946 5088776 OC::handleRequest( ) ../index.php:28
3 0.1423 7491280 OC\Route\Router->match( ) ../base.php:748
4 0.1664 8592152 call_user_func:{/Users/lreschke/Programming/core/lib/private/route/router.php:250} ( ) ../router.php:250
5 0.1664 8592216 __lambda_func( ) ../router.php:250
6 0.1665 8599064 require_once( '/Users/lreschke/Programming/core/apps/files_versions/ajax/getVersions.php' ) ../route.php(135) : runtime-created function:1
7 0.1801 9061096 OCA\Files_Versions\Storage::getUidAndFilename( ) ../getVersions.php:7
8 0.1801 9061144 OC\Files\Filesystem::getOwner( ) ../storage.php:45
```
Furthermore this adds the CSRF check as a nice-to-have addition, the requests accessing this are done via the jQuery AJAX methods and thus the header is automatically added to all requests already.
Otherwise when the file without any specified mimetype was accessed the error log was flooded with entries such as "Undefined index: mime", there can be multiple issues found about this in the forum and our bugtracker.
To test this access `/index.php/apps/files/ajax/mimeicon.php` with and without `$_GET['mime']`.
Fixes itself.
`$this->info` can very well contain an empty array or possibly other values. This means that when this code path is called a PHP Fatal error might get thrown which is not what we want.
Jenkins for ownCloud
Frank Karlitschek
Volkan Gezer
Morris Jobke
Lukas Reschke
Vincent Petry
Thomas Müller
Andreas Fischer
Robin Appelman
Jan-Christoph Borchardt
Bjoern Schiessle
Robin Appelman
Robin McCorkell
Arthur Schiwon