time gcc -m32 -O2 -I. -I../sqliteSrc/sqlite-3.3.17/src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -c sqlite3.c -fPIC -DPIC -o .libs/sqlite3.o real 0m20.266s user 0m19.773s sys 0m0.444s time gcc -m32 -O2 -I. -I../sqliteSrc/sqlite-3.3.17/src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -c sqlite3.c -o sqlite3.o >/dev/null 2>&1 real 0m13.050s user 0m12.405s sys 0m0.336s Linux suse 10.0 (amd x2 3800) gcc version 4.0.2 20050901 (prerelease) (SUSE Linux) [EMAIL PROTECTED] wrote: "C.Peachment" wrote: > With the suggestion that the problem was a compiler bug > in PellesC for Windows, I posted a message on their forum. > One response suggested a couple of configuration changes > and also said to wait a while because it took a long time to > compile. >
Fascinating. GCC (version 4.1.0) takes less than 25 seconds to compile and link a command-line shell using the amalgamation with full optimization (-O3) - which as far as I know is as slow as you can make the compiler run. With all optimization turned off, the whole thing builds in 3.430 seconds (wall-clock time). One of the reasons proffered for not using the amalgamation is that compiles go faster if you do not have to recompile the whole thing. I read that and thought "4 seconds is too slow?" But perhaps GCC is just a really fast compiler and the person who said that is just using a much slower compiler. I'm curious to see a comparison of the size and speed of the executables that result from GCC and its more sluggish competitors. Does anybody have any data? -- D. Richard Hipp ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] ----------------------------------------------------------------------------- [EMAIL PROTECTED] wrote: "C.Peachment" wrote: > With the suggestion that the problem was a compiler bug > in PellesC for Windows, I posted a message on their forum. > One response suggested a couple of configuration changes > and also said to wait a while because it took a long time to > compile. > Fascinating. GCC (version 4.1.0) takes less than 25 seconds to compile and link a command-line shell using the amalgamation with full optimization (-O3) - which as far as I know is as slow as you can make the compiler run. With all optimization turned off, the whole thing builds in 3.430 seconds (wall-clock time). One of the reasons proffered for not using the amalgamation is that compiles go faster if you do not have to recompile the whole thing. I read that and thought "4 seconds is too slow?" But perhaps GCC is just a really fast compiler and the person who said that is just using a much slower compiler. I'm curious to see a comparison of the size and speed of the executables that result from GCC and its more sluggish competitors. Does anybody have any data? -- D. Richard Hipp ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] ----------------------------------------------------------------------------- [EMAIL PROTECTED] wrote: "C.Peachment" wrote: > With the suggestion that the problem was a compiler bug > in PellesC for Windows, I posted a message on their forum. > One response suggested a couple of configuration changes > and also said to wait a while because it took a long time to > compile. > Fascinating. GCC (version 4.1.0) takes less than 25 seconds to compile and link a command-line shell using the amalgamation with full optimization (-O3) - which as far as I know is as slow as you can make the compiler run. With all optimization turned off, the whole thing builds in 3.430 seconds (wall-clock time). One of the reasons proffered for not using the amalgamation is that compiles go faster if you do not have to recompile the whole thing. I read that and thought "4 seconds is too slow?" But perhaps GCC is just a really fast compiler and the person who said that is just using a much slower compiler. I'm curious to see a comparison of the size and speed of the executables that result from GCC and its more sluggish competitors. Does anybody have any data? -- D. Richard Hipp ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
