[TYPO3-performance] TS-Rendering - IMG_RESOURCE - 622 ms - Solution

[Martin Kutschker]

JoH asenau schrieb:
>>>>> So I don't think we can say for sure, that the new way definitely
>>>>> will be a performance increase, just by comparing the functions
>>>>> directly.
>>>>> Each time the new check decides "false", while the old check would
>>>>> have decided "true", we will create a new file.
>>>> I guess that depends whether the mtime changes a lot without any
>>>> actual change of the content. This might happen if you touch()
>>>> files for some reason. The file size shouldn't change without
>>>> reason. Any change of size must force a recreation (the check for
>>>> the mtime can be omitted in this case).
>>> i sometimes had some trouble with servers where the ftp-client set
>>> chmod 700 on all files, so the apache had no right to alter. So i
>>> have to make an chmod -R *
>>>
>>> but IMHO that is an wrong server setup, so it should not get too much
>>> attention:)
>> Is a config switch worth the hassle? A single if will cost less than
>> a file system access, so it won't hurt much. IMHO in normal
>> circumstances mod. time is enough, but those with special needs can
>> use the old md5 method.
> 
> So let's see which options we've got so far:
> 1 different mtime => same content or different content
> 2 different mtime => same size or different size
> 3 different size => different mtime and (different content or same content)
> 4 different content => different mtime and (different size or same size)
> 
> Since we want to avoid 4 the only way to go seems to be 3, since 1 and 2
> might lead to a performance loss.

I'm either dumb or still lack coffee at this time of day. I don't get what's left and right of the
arrow.

So I probably just phrase 3 in other words:

If the size differs it's clear that the content has changed.
If only the mtime changed the content could have changed.
In this case we *could* check the md5 hash to be sure.

> There 's still one problem left:
> What if the size didn't change at all, but the content did?
> This might be an edge case for true color photos like TIF or JPG, but not
> for GIF.

I stated that alot earlier in this thread :)

> So it seems there is a reason why the current check is using content and not
> size or time.
> On the other hand it might be a good idea to do a double check:
> First check the mtime and _only_ if that has changed, check the content.

Same conclusion as mine :)

> This way we would still get a much better performance, because only changed
> files would be checked by the slower function, while we would still be on
> the safe side for all scenarios.

I agree. Rupi, what do you think?

Masi