tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: [OT] Setting HTTP response headers caching for 1 year doesn't work
Date Wed, 19 Jan 2011 16:37:59 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

André,

On 1/19/2011 6:52 AM, André Warnier wrote:
> #include <stdio.h>
> 
> int main(int argc, char *argv[]) {
> 
> int thousand = 1000;
> int sixty = 60;
> int twentyfour = 24;
> int hundred = 100;
> int three = 3;
> 
>   int cacheTime1 = (1000 * 60 * 60 * 24 * 100 * 3);
>   long cacheTime2 = ((long)1000 * 60 * 60 * 24 * 100 * 3);
>   long long cacheTime3 = ((long long)1000 * 60 * 60 * 24 * 100 * 3);
>   long long cacheTime4 = (1000 * 60 * 60 * 24 * 100 * (long long)3);
>   long long cacheTime5 = (thousand * sixty * sixty * twentyfour *
> hundred * three);
> 
>   printf("%d\n%ld\n%lld\n%lld\n%lld\n", cacheTime1, cacheTime2, cacheTime3,
> cacheTime4,cacheTime5);
> 
>   return 0;
> }
> 
> aw@arthur:~/tests$ cc -ansi -pedantic -Wall -o longtime2 longtime2.c &&
> ./longtime2
> longtime2.c: In function 'main':
> longtime2.c:11: warning: integer overflow in expression
> longtime2.c:12: warning: integer overflow in expression
> longtime2.c:13: warning: ISO C90 does not support 'long long'
> longtime2.c:13: warning: ISO C90 does not support 'long long'
> longtime2.c:14: warning: ISO C90 does not support 'long long'
> longtime2.c:14: warning: integer overflow in expression        <=== ****

Line 14 looks like "long long cacheTime4..." not the one you're looking
for. Yours is on line 15 where no warning was indicated.

> Maybe the Java compiler cannot afford to do that, because it is used in
> "just-in-time" compilations ?

No, Java has a well-defined conversion system regardless of the
underlying platform, so the compiler should be able to check. It just
doesn't apparently.

>> I couldn't make head or tail out of the timeit() function's return
>> value, so I just used 'time' from the command line to see what really
>> happened.
>>
> Neither could I, so I rewrote your test program somewhat (and decreased
> the loop by a factor 10, to be practical):

(Just get a bigger machine :)

> #!/usr/bin/perl
> 
> use Benchmark;
> 
> my $loops = 10000000;
> NORMAL:{
> my $left = 10;
> my $right = 3;
> my $res = $left / $right;
> print "\'NORMAL\' result : $res\n";
> my $t0 = Benchmark->new;
> for (my $i=0; $i<$loops; $i++) {
>   my $res = $left / $right;
> }
> my $t1 = Benchmark->new;
> my $td = timediff($t1, $t0);
> print "\'NORMAL\' times :",timestr($td),"\n";
> }
> 
> INTEGER:{
> use integer;

So, does "use integer" set the arithmetic evaluation strategy? I've
never see that before (though I'm not a seasoned Perl programmer).

> Note that for the BIGFLOAT and BIGINT sections, you need to be *really*
> patient.
> I interrupted at after maybe 10 minutes..

What, you didn't run it yourself? :( I ran mine for you :)

> Funny thing is, the INTEGER section seems actually slower than the
> standard one.

I'll have to run your test and see what happens.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk03E2YACgkQ9CaO5/Lv0PBRRQCgsueTU+jBVycQrS4b9eRapUaE
3FIAnjr5EhzCckAwhisNS99ZrxjdDqFV
=Q0gR
-----END PGP SIGNATURE-----

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


Mime
View raw message