Re: Increased memory consumption due to url encoding

2016-08-31 Thread Svetlin Zarev
Thanks Chris,

I've created a pull request on github:
https://github.com/apache/tomcat85/pull/3

> and then look at the diffs manually
It's an almost complete rewrite and has very little in common with the old
encoder

Svetlin

2016-08-30 20:56 GMT+03:00 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Svetlin,
>
> On 8/28/16 12:57 PM, Svetlin Zarev wrote:
> > Hi,
> >
> > Today I had some free time, so I implemented a more (memory and
> > performance wise) efficient URLEncoder [1]  and I'd like to
> > contribute it if there is interest for improvement in that area. My
> > encoder has close to zero allocation rate (unless there is very
> > high concurrency for the encode() operations, but still will be
> > much more memory efficient than the current encoder)  and encodes
> > 2-4 times faster than the current implementation. It is available @
> > [1]. I'm open for reviews, critiques, questions, suggestions, etc.
> >
> > [1] https://github.com/SvetlinZarev/UrlEncoder
>
> Can you post this as a pull request, patch, or similar? Nobody really
> wants to download this code, replace their own local code, and then
> look at the diffs manually. I suspect that's why nobody has looked at
> it, yet.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXxcjVAAoJEBzwKT+lPKRYsCMQAKy/pVLDeSWvcbbHMYwOLwa5
> xhBc3R0ev51qt9rMbkBTQhOZM/beM5u9AcOevFNaQlqr6knxui0R2v7fcM7LKxzU
> w8iRxe+8w1GxA/nPVmUAXU5geL7Z7gnyIf+GBhOlxn8R4cXfkvRBCOP0shZpIXPr
> fF4buxBLGOii3ApiYELdxxM6andEXc8SHd+CoCm9fc3GPMVyR4eFDEg7nNc1Y44t
> FWRBOXNCf0nJRHUDswEqK2ZTlTvd1GFTInLAy9m30uJRzkGDa3ytgfikaBE/c/Je
> ctCtz/g9xUk715YFhm23ZAmGvzi3bWBj9PZ3yTixf646Oa8WPsWWm7vALjRNZcfG
> j8Cy0ugEo1kT9wr1anIdPtr4q22E3k4Gu8SAhEObcO65dFtdZ2kvQ+tJxTceOmjn
> vyplST7kVORuhtWf+rj+L+VgHZsRR54+5C8a9Hf1/TSaI1ztWJbFIYuJr+YgnGw5
> Z264C/rWPr4fd1BRNCwJz9iHoC24IuTJAiNNcVQHrs7xKn16sW4Sq/hM5AE7oJ/5
> RhvpLtZPQmxpqVjvxPallYT0/lMN3CJ26m7A5rf0242MMf9zIsxsnnNUznhh2zNR
> gyJsTHJZ2o4tuwEclimzxrwIbO5RxgIeoTdxTbhsE4775oSQ3VHvE07yDPLlqRAh
> My3/WOXu8myi0WeLoRzE
> =5SJi
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Increased memory consumption due to url encoding

2016-08-30 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Svetlin,

On 8/28/16 12:57 PM, Svetlin Zarev wrote:
> Hi,
> 
> Today I had some free time, so I implemented a more (memory and
> performance wise) efficient URLEncoder [1]  and I'd like to
> contribute it if there is interest for improvement in that area. My
> encoder has close to zero allocation rate (unless there is very
> high concurrency for the encode() operations, but still will be
> much more memory efficient than the current encoder)  and encodes
> 2-4 times faster than the current implementation. It is available @
> [1]. I'm open for reviews, critiques, questions, suggestions, etc.
> 
> [1] https://github.com/SvetlinZarev/UrlEncoder

Can you post this as a pull request, patch, or similar? Nobody really
wants to download this code, replace their own local code, and then
look at the diffs manually. I suspect that's why nobody has looked at
it, yet.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXxcjVAAoJEBzwKT+lPKRYsCMQAKy/pVLDeSWvcbbHMYwOLwa5
xhBc3R0ev51qt9rMbkBTQhOZM/beM5u9AcOevFNaQlqr6knxui0R2v7fcM7LKxzU
w8iRxe+8w1GxA/nPVmUAXU5geL7Z7gnyIf+GBhOlxn8R4cXfkvRBCOP0shZpIXPr
fF4buxBLGOii3ApiYELdxxM6andEXc8SHd+CoCm9fc3GPMVyR4eFDEg7nNc1Y44t
FWRBOXNCf0nJRHUDswEqK2ZTlTvd1GFTInLAy9m30uJRzkGDa3ytgfikaBE/c/Je
ctCtz/g9xUk715YFhm23ZAmGvzi3bWBj9PZ3yTixf646Oa8WPsWWm7vALjRNZcfG
j8Cy0ugEo1kT9wr1anIdPtr4q22E3k4Gu8SAhEObcO65dFtdZ2kvQ+tJxTceOmjn
vyplST7kVORuhtWf+rj+L+VgHZsRR54+5C8a9Hf1/TSaI1ztWJbFIYuJr+YgnGw5
Z264C/rWPr4fd1BRNCwJz9iHoC24IuTJAiNNcVQHrs7xKn16sW4Sq/hM5AE7oJ/5
RhvpLtZPQmxpqVjvxPallYT0/lMN3CJ26m7A5rf0242MMf9zIsxsnnNUznhh2zNR
gyJsTHJZ2o4tuwEclimzxrwIbO5RxgIeoTdxTbhsE4775oSQ3VHvE07yDPLlqRAh
My3/WOXu8myi0WeLoRzE
=5SJi
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Increased memory consumption due to url encoding

2016-08-28 Thread Svetlin Zarev
Hi,

Today I had some free time, so I implemented a more (memory and performance
wise) efficient URLEncoder [1]  and I'd like to contribute it if there is
interest for improvement in that area. My encoder has close to zero
allocation rate (unless there is very high concurrency for the encode()
operations, but still will be much more memory efficient than the current
encoder)  and encodes 2-4 times faster than the current implementation. It
is available @ [1]. I'm open for reviews, critiques, questions,
suggestions, etc.

[1] https://github.com/SvetlinZarev/UrlEncoder

Svetlin


Re: Increased memory consumption due to url encoding

2016-08-12 Thread Rainer Jung

Am 11.08.2016 um 21:16 schrieb Jose María Zaragoza:

2016-08-10 14:29 GMT+02:00 Lazar Kirchev :

Hello Christopher,

I tried with 32 MB and even 24 MB heap and the CPU usage and response time
remained the almost the same (the difference is negligible) as with 1 GB
heap. The cumulative allocated memory for the HeapByteBuffer remains about
400 MB, but of course the frequency of GCs is increased.



A newbie question:

if you tried with 32 MB ( I guess -Xmx size ) , why is not raised an OOM error ?
are those 400MB allocated outside heap ?


Allocation size is not the same as size of objects in memory. An 
allocation of 400 MB during some test means the sum of the sizes of all 
objects that were created was 400 MB. The life time of those objects 
could be very short. So it is possible that only few of them were in 
memory at the same time.


An extreme example: suppose you create 1000 objects per second (or one 
per millisecond) each of size 10 KB. That means you have an allocation 
rate of 10 MB/s or after one minute 600 MB. Assume further that each 
object only lives 5 milliseconds, because it maybe is created and used 
only inside a method that runs very short. Then at each point in time 
about 5 of those objects exist which makes up only 50 KB of memory.


For many java programs the popular slogan "most objects die young" is 
correct, which means you can have high allocation rates with relatively 
small memory. Allocation is relatively cheap in Java. As always details 
go far beyond such simplistic slogans.


Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Increased memory consumption due to url encoding

2016-08-11 Thread Jose María Zaragoza
2016-08-10 14:29 GMT+02:00 Lazar Kirchev :
> Hello Christopher,
>
> I tried with 32 MB and even 24 MB heap and the CPU usage and response time
> remained the almost the same (the difference is negligible) as with 1 GB
> heap. The cumulative allocated memory for the HeapByteBuffer remains about
> 400 MB, but of course the frequency of GCs is increased.


A newbie question:

if you tried with 32 MB ( I guess -Xmx size ) , why is not raised an OOM error ?
are those 400MB allocated outside heap ?

Thanks

>
> Regards,
> Lazar
>
> On Tue, Aug 9, 2016 at 7:27 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Lazar,
>>
>> On 8/9/16 8:40 AM, Lazar Kirchev wrote:
>> > Hello! When handling requests which make use of request dispatcher,
>> > Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This
>> > seems to come from the encoding of the path introduced with this
>> > change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/
>> > apache/catalina/core/ApplicationContext.java?r1=1741024=1741023
>> hrev=
>> >
>> >
>> 1741024
>> > 5 requests to a very simple servlet which only gets a request
>> > dispatcher for some path lead to allocation of about 400 MB.
>> > However, after a GC they are freed and this actually does not
>> > influence CPU or response time. Has anybody noticed this effect and
>> > what do you think about it?
>>
>> What happens if you set the heap size very low (e.g. 32MiB) and run
>> the same test? Does the memory usage grow to 400MiB, or does the
>> request performance start to degrade?
>>
>> I'm curious if you are just seeing the effect of the GC doing its job
>> correctly.
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBCAAGBQJXqgSPAAoJEBzwKT+lPKRY6+8P/2vzkhQJkPKjYAFln5wkbPp7
>> lbIVDvcH5546ch4nTQsrMPiUT/m71wwDytn6qOMzP9dIbAXjC3tBJI+nqDthkZyQ
>> ScmIi2A93JQl0aOHrMzCuS3cFk0sNdwK3n2sk8ZcFd5/KZ5cwxkyeUqwiRVbU5bA
>> MjJsEiq+r7Vgo6V3mAxMwaKS7mwLc1hcgJMrhJA8gjfeHzxhzeG0mcrIGrg5cGvl
>> mTHLovt9x1ts4KNApdt4DUSg+Yt3Fx/Gj1aoL1x1KbPM9VIJSb52IG/03WPMxIkq
>> fSM71fbZHpjZy19uV+e50sHzM0fg96RsrlQ7m5Uvjgqkz6zxNYlsX3tC0z1E7oEr
>> wq1Qi0C3dCbRe6vqnN3znYg+DyrlZ/R+qO8+35GD3ljiiDuJLpevYFNVjNceFn1Y
>> Qno6W8/2Dp1eHTxaAAVY4hhbdZyzLgxD+lOu+THkOnoZwx8Bw8TXStHIdbwtMfSz
>> 9jGuZU4W/t9uTgW6ZnauS16v2EKUbicFY9L5FB3vrRUi1qm+pYVMUdQoZtVl2yL6
>> ZoDTEZTGzvpNUoJLGDzWjp9QkXkVGIrgM7+uYXIDcMUn7QrmLLab7oGJO1pLuAlz
>> 9BJiLpjqja5eAHp/Bz1ud5ZZhBaNECJIqhkjma/+LAC1Meullf3ct4FRmL8aGfUz
>> m0ntWlqyXwr6EbmRjbFE
>> =FTq+
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Increased memory consumption due to url encoding

2016-08-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lazar,

On 8/10/16 8:29 AM, Lazar Kirchev wrote:
> I tried with 32 MB and even 24 MB heap and the CPU usage and
> response time remained the almost the same (the difference is
> negligible) as with 1 GB heap. The cumulative allocated memory for
> the HeapByteBuffer remains about 400 MB, but of course the
> frequency of GCs is increased.

Sounds like Tomcat generates a bunch of temporary garbage with that
byte buffer change, but because the objects are so short-lived, they
have no impact on the GC performance, and thus no impact on the
response time.

Remember that GC performance depends upon the number of /live/ objects
moving between generations, not the number of total objects or memory
"used" by garbage. Actual garbage is basically ignored during a GC run.

- -chris

> On Tue, Aug 9, 2016 at 7:27 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Lazar,
> 
> On 8/9/16 8:40 AM, Lazar Kirchev wrote:
 Hello! When handling requests which make use of request
 dispatcher, Tomcat 7.0.70 allocates more memory in comparison
 to 7.0.69. This seems to come from the encoding of the path
 introduced with this change
 http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/ 
 apache/catalina/core/ApplicationContext.java?r1=1741024=1741023&
pat
>
 
hrev=
 
 
> 1741024
 5 requests to a very simple servlet which only gets a
 request dispatcher for some path lead to allocation of about
 400 MB. However, after a GC they are freed and this actually
 does not influence CPU or response time. Has anybody noticed
 this effect and what do you think about it?
> 
> What happens if you set the heap size very low (e.g. 32MiB) and
> run the same test? Does the memory usage grow to 400MiB, or does
> the request performance start to degrade?
> 
> I'm curious if you are just seeing the effect of the GC doing its
> job correctly.
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXq0gVAAoJEBzwKT+lPKRYanIP/1fZ436QaLhfN/8ea3foT5gX
0fv9wK+sacg4ZTNyxVLwJa03GfS0SDNXBz9WKLa3FBxqi7WopRNqEtnH28nmCNnp
34toy+k5+IWOATn4xyboUmp6CXHTQieTO3OGmQBEg8CMOipSluOPtkq0qfPqaqKz
s//gKq0o2y3LG+7SrbHeHzf8GJiZQnIASkXBJxZ5dncJx5tHAXKbA0ji6NFlhqat
Y3E/16griZSoqhm/mVRHVZfEdvsebMDmC7cDxxakJpcxr6MjZL8aw9Tdop01aA7c
0U5ndG6jT7vJ8V1iYKblZkM0xgPuBZQln8MHuwuRVXcPgkVHhf2AOiXKrcLWtXCh
vnc0zRRn+Qat3FXrqUIv39r51+OtCO+c860Rny/t3gUXV0VSGsBLW8nAvCe8dLPf
spc4yJPEICOVsUcOk04P4ktwXQYXR6DzcV09tpHdbIeQ23YHoYAvW4O93wp4AhJ3
/rI3t4dCCFWpxutsVxBmrVpgbLJg78kpZTauu35Q0oJBHPYGxjn+mOdqZMSXnn3X
3afrr9nmneyW/YUEj0sUclr5HtbqHojStphf7SYczMlnDpOg5DVGGnSJLK2gvJVQ
Plu1qsA0uJ1NUEFRLkQ0FwyxSZl8EtfSQHqZnh/pgulto38dRa7kSRgUylHWnpI3
9uV9gLnKuBWlqg+y16UV
=tW0i
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Increased memory consumption due to url encoding

2016-08-10 Thread Lazar Kirchev
Hello Christopher,

I tried with 32 MB and even 24 MB heap and the CPU usage and response time
remained the almost the same (the difference is negligible) as with 1 GB
heap. The cumulative allocated memory for the HeapByteBuffer remains about
400 MB, but of course the frequency of GCs is increased.

Regards,
Lazar

On Tue, Aug 9, 2016 at 7:27 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Lazar,
>
> On 8/9/16 8:40 AM, Lazar Kirchev wrote:
> > Hello! When handling requests which make use of request dispatcher,
> > Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This
> > seems to come from the encoding of the path introduced with this
> > change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/
> > apache/catalina/core/ApplicationContext.java?r1=1741024=1741023
> hrev=
> >
> >
> 1741024
> > 5 requests to a very simple servlet which only gets a request
> > dispatcher for some path lead to allocation of about 400 MB.
> > However, after a GC they are freed and this actually does not
> > influence CPU or response time. Has anybody noticed this effect and
> > what do you think about it?
>
> What happens if you set the heap size very low (e.g. 32MiB) and run
> the same test? Does the memory usage grow to 400MiB, or does the
> request performance start to degrade?
>
> I'm curious if you are just seeing the effect of the GC doing its job
> correctly.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXqgSPAAoJEBzwKT+lPKRY6+8P/2vzkhQJkPKjYAFln5wkbPp7
> lbIVDvcH5546ch4nTQsrMPiUT/m71wwDytn6qOMzP9dIbAXjC3tBJI+nqDthkZyQ
> ScmIi2A93JQl0aOHrMzCuS3cFk0sNdwK3n2sk8ZcFd5/KZ5cwxkyeUqwiRVbU5bA
> MjJsEiq+r7Vgo6V3mAxMwaKS7mwLc1hcgJMrhJA8gjfeHzxhzeG0mcrIGrg5cGvl
> mTHLovt9x1ts4KNApdt4DUSg+Yt3Fx/Gj1aoL1x1KbPM9VIJSb52IG/03WPMxIkq
> fSM71fbZHpjZy19uV+e50sHzM0fg96RsrlQ7m5Uvjgqkz6zxNYlsX3tC0z1E7oEr
> wq1Qi0C3dCbRe6vqnN3znYg+DyrlZ/R+qO8+35GD3ljiiDuJLpevYFNVjNceFn1Y
> Qno6W8/2Dp1eHTxaAAVY4hhbdZyzLgxD+lOu+THkOnoZwx8Bw8TXStHIdbwtMfSz
> 9jGuZU4W/t9uTgW6ZnauS16v2EKUbicFY9L5FB3vrRUi1qm+pYVMUdQoZtVl2yL6
> ZoDTEZTGzvpNUoJLGDzWjp9QkXkVGIrgM7+uYXIDcMUn7QrmLLab7oGJO1pLuAlz
> 9BJiLpjqja5eAHp/Bz1ud5ZZhBaNECJIqhkjma/+LAC1Meullf3ct4FRmL8aGfUz
> m0ntWlqyXwr6EbmRjbFE
> =FTq+
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Increased memory consumption due to url encoding

2016-08-09 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lazar,

On 8/9/16 8:40 AM, Lazar Kirchev wrote:
> Hello! When handling requests which make use of request dispatcher,
> Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This
> seems to come from the encoding of the path introduced with this
> change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/ 
> apache/catalina/core/ApplicationContext.java?r1=1741024=1741023
hrev=
>
> 
1741024
> 5 requests to a very simple servlet which only gets a request 
> dispatcher for some path lead to allocation of about 400 MB.
> However, after a GC they are freed and this actually does not
> influence CPU or response time. Has anybody noticed this effect and
> what do you think about it?

What happens if you set the heap size very low (e.g. 32MiB) and run
the same test? Does the memory usage grow to 400MiB, or does the
request performance start to degrade?

I'm curious if you are just seeing the effect of the GC doing its job
correctly.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXqgSPAAoJEBzwKT+lPKRY6+8P/2vzkhQJkPKjYAFln5wkbPp7
lbIVDvcH5546ch4nTQsrMPiUT/m71wwDytn6qOMzP9dIbAXjC3tBJI+nqDthkZyQ
ScmIi2A93JQl0aOHrMzCuS3cFk0sNdwK3n2sk8ZcFd5/KZ5cwxkyeUqwiRVbU5bA
MjJsEiq+r7Vgo6V3mAxMwaKS7mwLc1hcgJMrhJA8gjfeHzxhzeG0mcrIGrg5cGvl
mTHLovt9x1ts4KNApdt4DUSg+Yt3Fx/Gj1aoL1x1KbPM9VIJSb52IG/03WPMxIkq
fSM71fbZHpjZy19uV+e50sHzM0fg96RsrlQ7m5Uvjgqkz6zxNYlsX3tC0z1E7oEr
wq1Qi0C3dCbRe6vqnN3znYg+DyrlZ/R+qO8+35GD3ljiiDuJLpevYFNVjNceFn1Y
Qno6W8/2Dp1eHTxaAAVY4hhbdZyzLgxD+lOu+THkOnoZwx8Bw8TXStHIdbwtMfSz
9jGuZU4W/t9uTgW6ZnauS16v2EKUbicFY9L5FB3vrRUi1qm+pYVMUdQoZtVl2yL6
ZoDTEZTGzvpNUoJLGDzWjp9QkXkVGIrgM7+uYXIDcMUn7QrmLLab7oGJO1pLuAlz
9BJiLpjqja5eAHp/Bz1ud5ZZhBaNECJIqhkjma/+LAC1Meullf3ct4FRmL8aGfUz
m0ntWlqyXwr6EbmRjbFE
=FTq+
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Increased memory consumption due to url encoding

2016-08-09 Thread Lazar Kirchev
Hello!
When handling requests which make use of request dispatcher, Tomcat 7.0.70
allocates more memory in comparison to 7.0.69. This seems to come from the
encoding of the path introduced with this change
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/
apache/catalina/core/ApplicationContext.java?r1=1741024=1741023=
1741024
5 requests to a very simple servlet which only gets a request
dispatcher for some path lead to allocation of about 400 MB. However, after
a GC they are freed and this actually does not influence CPU or response
time.
Has anybody noticed this effect and what do you think about it?

Kind regards,
Lazar