Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #5827 > unrolled thread
| Started by | Dominique Ottello <air.intakes@fra.fr.invalid> |
|---|---|
| First post | 2012-05-06 11:12 +0200 |
| Last post | 2012-05-08 09:49 +0200 |
| Articles | 20 on this page of 143 — 18 participants |
Back to article view | Back to comp.lang.php
Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 11:12 +0200
Re: Windows binaries 64bit for PHP "J.O. Aho" <user@example.net> - 2012-05-06 11:51 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 17:23 +0200
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-06 18:11 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 19:04 +0200
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-07 20:05 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-07 20:23 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-07 17:16 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-07 16:49 -0500
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-07 15:01 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-07 20:15 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-07 20:37 -0700
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-08 09:11 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-08 08:21 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-08 11:17 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:14 -0400
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-09 17:05 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 12:21 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-09 19:36 +0100
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-09 21:31 +0200
Re: Windows binaries 64bit for PHP Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-05-12 11:12 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 22:56 +0100
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-14 10:51 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-14 10:17 +0100
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-14 19:26 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 00:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:52 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 08:50 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 08:01 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 21:01 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 15:12 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 11:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 06:50 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 13:57 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:29 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-11 13:32 -0500
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 20:01 +0100
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-08 22:25 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-08 21:29 -0500
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 09:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:17 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 16:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 10:38 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 16:54 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 12:23 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-11 13:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 07:38 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-11 15:44 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:30 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-11 13:38 -0500
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-14 10:48 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-09 11:34 -0500
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 11:30 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 15:52 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 13:46 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:10 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 00:19 +0200
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 15:28 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:53 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 13:15 -0700
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-10 21:48 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 17:05 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 14:29 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 19:35 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 18:50 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 22:22 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-11 10:03 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 13:56 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 11:58 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 06:51 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 21:11 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 15:29 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 21:53 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:11 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-12 01:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 20:44 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:38 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:36 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 14:01 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:34 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-11 20:58 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 15:30 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-11 21:46 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:14 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-12 14:42 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 11:04 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-12 18:40 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 15:49 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 22:59 +0100
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-13 13:46 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-13 07:50 -0500
Re: Windows binaries 64bit for PHP Anders Wegge Keller <wegge@wegge.dk> - 2012-05-13 16:15 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 10:36 -0400
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 09:06 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-13 18:54 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 13:27 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-13 22:26 -0500
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 09:51 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 08:04 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 14:25 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 09:37 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 16:22 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 16:45 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:07 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 22:37 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:47 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-14 16:53 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:06 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-14 20:36 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:53 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 23:04 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:48 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 23:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:57 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:38 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 20:46 -0400
Re: Windows binaries 64bit for PHP PlastiqueMAN <plastique@man.com> - 2012-05-23 22:45 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 00:18 -0400
Re: Windows binaries 64bit for PHP Stig Vestøl <stig@vestoldata.no> - 2012-05-24 11:40 +0200
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-24 12:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 09:12 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-24 16:29 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-24 20:41 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 15:17 -0400
Re: Windows binaries 64bit for PHP Luuk <luuk@invalid.lan> - 2012-05-11 21:53 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:15 -0400
Re: Windows binaries 64bit for PHP Luuk <luuk@invalid.lan> - 2012-05-12 10:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 07:29 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-12 06:47 -0500
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:40 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 01:07 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:53 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 08:49 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 08:02 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 21:09 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 15:32 -0400
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-16 17:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-16 12:35 -0400
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-16 19:35 +0200
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-06 18:30 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 19:04 +0200
Re: Windows binaries 64bit for PHP "J.O. Aho" <user@example.net> - 2012-05-12 16:45 +0200
Re: Windows binaries 64bit for PHP "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-05-08 09:49 +0200
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Dominique Ottello <air.intakes@fra.fr.invalid> |
|---|---|
| Date | 2012-05-06 11:12 +0200 |
| Subject | Windows binaries 64bit for PHP |
| Message-ID | <gpfcq75t3bo42q4qu58fsiigd5rq7712rb@4ax.com> |
Hi, ApacheLounge http://www.apachelounge.com/download/win64/ and MySQL http://www.mysql.com/downloads/mysql/5.5.html gives us Windows 64 bit binaries for Apache and MySQL. PHP does not do it! Why? Could it be that complicated to compile for 32 AND 64 bit?
[toc] | [next] | [standalone]
| From | "J.O. Aho" <user@example.net> |
|---|---|
| Date | 2012-05-06 11:51 +0200 |
| Message-ID | <a0mvsbFq74U1@mid.individual.net> |
| In reply to | #5827 |
Dominique Ottello wrote: > Hi, > > ApacheLounge http://www.apachelounge.com/download/win64/ > and MySQL http://www.mysql.com/downloads/mysql/5.5.html > gives us Windows 64 bit binaries for Apache and MySQL. > > PHP does not do it! > Why? Could it be that complicated to compile for 32 AND 64 bit? Why don't Microsoft do it? All the Linuxes and Unixes does that. -- //Aho
[toc] | [prev] | [next] | [standalone]
| From | Dominique Ottello <air.intakes@fra.fr.invalid> |
|---|---|
| Date | 2012-05-06 17:23 +0200 |
| Message-ID | <ja5dq7tb9nqtn15artbs4fhn1nsjh7k2iu@4ax.com> |
| In reply to | #5828 |
"J.O. Aho" <user@example.net> écrivait : > > PHP does not do it! > > Why? Could it be that complicated to compile for 32 AND 64 bit? > > Why don't Microsoft do it? All the Linuxes and Unixes does that. This is a typical response of Linux user who brings strictly no explanation to my question. Jesuit Response: You answer a question with another question. Apache makes 64 bit binaries for Windows MySQL makes 64 bit binaries for Windows PHP does not.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2012-05-06 18:11 +0200 |
| Message-ID | <4FA6A2C4.6030708@arnowelzel.de> |
| In reply to | #5829 |
Dominique Ottello, 06.05.2012 17:23: > "J.O. Aho" <user@example.net> écrivait : > >>> PHP does not do it! >>> Why? Could it be that complicated to compile for 32 AND 64 bit? >> >> Why don't Microsoft do it? All the Linuxes and Unixes does that. > This is a typical response of Linux user who brings strictly no > explanation to my question. > Jesuit Response: You answer a question with another question. > > Apache makes 64 bit binaries for Windows > MySQL makes 64 bit binaries for Windows > PHP does not. Why do you need 64 bit binaries? -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de
[toc] | [prev] | [next] | [standalone]
| From | Dominique Ottello <air.intakes@fra.fr.invalid> |
|---|---|
| Date | 2012-05-06 19:04 +0200 |
| Message-ID | <phbdq7hba71cm2pefn8i6shires5p85fd8@4ax.com> |
| In reply to | #5830 |
Arno Welzel <usenet@arnowelzel.de> écrivait : > Why do you need 64 bit binaries? Because 32 bit PHP binaries do not work with Apache 64 bit.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2012-05-07 20:05 +0200 |
| Message-ID | <4FA80EF3.5000806@arnowelzel.de> |
| In reply to | #5832 |
Dominique Ottello, 06.05.2012 19:04: > Arno Welzel <usenet@arnowelzel.de> écrivait : > >> Why do you need 64 bit binaries? > Because 32 bit PHP binaries do not work with Apache 64 bit. Ok - why do you need 64 bit at all for a web server? I run a web server for multiple domains with more than 1 mio hits in total per month where about 50% are handled by an Apache PHP module. I also use XCache and so far neither Apache nor XCache are getting to any limit (XCache runs fine with 128 MB cache and only uses about 60-70 MB of it and the whole system does not allocate more than about 1,5-1,8 GB of RAM). -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-07 20:23 +0100 |
| Message-ID | <jo97fc$een$1@news.albasani.net> |
| In reply to | #5838 |
Arno Welzel wrote: > Dominique Ottello, 06.05.2012 19:04: > >> Arno Welzel <usenet@arnowelzel.de> écrivait : >> >>> Why do you need 64 bit binaries? >> Because 32 bit PHP binaries do not work with Apache 64 bit. > > Ok - why do you need 64 bit at all for a web server? > helps a lot when rescaling images on the fly... > I run a web server for multiple domains with more than 1 mio hits in > total per month where about 50% are handled by an Apache PHP module. I > also use XCache and so far neither Apache nor XCache are getting to any > limit (XCache runs fine with 128 MB cache and only uses about 60-70 MB > of it and the whole system does not allocate more than about 1,5-1,8 GB > of RAM). > > > -- To people who know nothing, anything is possible. To people who know too much, it is a sad fact that they know how little is really possible - and how hard it is to achieve it.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-07 17:16 -0400 |
| Message-ID | <jo9e31$vcc$1@dont-email.me> |
| In reply to | #5841 |
On 5/7/2012 3:23 PM, The Natural Philosopher wrote: > Arno Welzel wrote: >> Dominique Ottello, 06.05.2012 19:04: >> >>> Arno Welzel <usenet@arnowelzel.de> écrivait : >>> >>>> Why do you need 64 bit binaries? >>> Because 32 bit PHP binaries do not work with Apache 64 bit. >> >> Ok - why do you need 64 bit at all for a web server? >> > helps a lot when rescaling images on the fly... > > >> I run a web server for multiple domains with more than 1 mio hits in >> total per month where about 50% are handled by an Apache PHP module. I >> also use XCache and so far neither Apache nor XCache are getting to any >> limit (XCache runs fine with 128 MB cache and only uses about 60-70 MB >> of it and the whole system does not allocate more than about 1,5-1,8 GB >> of RAM). >> >> >> > > Why would you repeatedly rescale images on the fly? You should know what size you need for your pages and resize them once. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Peter H. Coffin" <hellsop@ninehells.com> |
|---|---|
| Date | 2012-05-07 16:49 -0500 |
| Message-ID | <slrnjqggqu.4ci.hellsop@nibelheim.ninehells.com> |
| In reply to | #5841 |
On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote:
> Arno Welzel wrote:
>> Dominique Ottello, 06.05.2012 19:04:
>>
>>> Arno Welzel <usenet@arnowelzel.de> ??crivait :
>>>
>>>> Why do you need 64 bit binaries?
>>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>>
>> Ok - why do you need 64 bit at all for a web server?
>>
> helps a lot when rescaling images on the fly...
Do you really do a lot of that, though? I mean, instead of pre-scaling
to a certain set number of sizes. Which seems more generally useful. If
you do, there's ways to handle that more rapidly and with less load than
the general purpose tools that PHP has wrappers for. EG: VIPS is
something like 4 times the speed at rescale than Gmagick.
--
I got told by a friend's ex-girlfriend that she could tell I was
a Linux geek from the way I *walked*.
-- Skud
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-05-07 15:01 -0700 |
| Message-ID | <VCXpr.36118$Ec.5371@newsfe16.iad> |
| In reply to | #5846 |
On 5/7/12 2:49 PM, Peter H. Coffin wrote: > On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote: >> Arno Welzel wrote: >>> Dominique Ottello, 06.05.2012 19:04: >>> >>>> Arno Welzel<usenet@arnowelzel.de> ??crivait : >>>> >>>>> Why do you need 64 bit binaries? >>>> Because 32 bit PHP binaries do not work with Apache 64 bit. >>> >>> Ok - why do you need 64 bit at all for a web server? >>> >> helps a lot when rescaling images on the fly... > > Do you really do a lot of that, though? I mean, instead of pre-scaling > to a certain set number of sizes. Which seems more generally useful. If > you do, there's ways to handle that more rapidly and with less load than > the general purpose tools that PHP has wrappers for. EG: VIPS is > something like 4 times the speed at rescale than Gmagick. > I haven't been following this thread, but I'll talk about my personal experience with image sizes. My particular company has a huge catalog of images. Right now, we do prescale the images to all the various sizes that might be needed, which works alright except that our design department every once in a while needs a new size. The amount of time required and effort to back-fill the old data is relatively large, and we don't necessarily need every size for every image (we just don't know where the images will show up eventually). Dynamic image scaling solves that problem nicely. With caching in place of course.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-07 20:15 -0400 |
| Message-ID | <jo9ojv$orv$1@dont-email.me> |
| In reply to | #5847 |
On 5/7/2012 6:01 PM, Daniel Pitts wrote: > On 5/7/12 2:49 PM, Peter H. Coffin wrote: >> On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote: >>> Arno Welzel wrote: >>>> Dominique Ottello, 06.05.2012 19:04: >>>> >>>>> Arno Welzel<usenet@arnowelzel.de> ??crivait : >>>>> >>>>>> Why do you need 64 bit binaries? >>>>> Because 32 bit PHP binaries do not work with Apache 64 bit. >>>> >>>> Ok - why do you need 64 bit at all for a web server? >>>> >>> helps a lot when rescaling images on the fly... >> >> Do you really do a lot of that, though? I mean, instead of pre-scaling >> to a certain set number of sizes. Which seems more generally useful. If >> you do, there's ways to handle that more rapidly and with less load than >> the general purpose tools that PHP has wrappers for. EG: VIPS is >> something like 4 times the speed at rescale than Gmagick. >> > I haven't been following this thread, but I'll talk about my personal > experience with image sizes. > > My particular company has a huge catalog of images. Right now, we do > prescale the images to all the various sizes that might be needed, which > works alright except that our design department every once in a while > needs a new size. The amount of time required and effort to back-fill > the old data is relatively large, and we don't necessarily need every > size for every image (we just don't know where the images will show up > eventually). > > Dynamic image scaling solves that problem nicely. With caching in place > of course. I've had clients who have the same need. It's pretty simple to scale a large number of images with a batch file (PHP, BASH, etc.), and proper naming/cataloging takes care of the rest. Who cares if you don't use all of the sizes? Disk space is cheap - much cheaper than processor time. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-05-07 20:37 -0700 |
| Message-ID | <hy0qr.1437$HW6.1133@newsfe20.iad> |
| In reply to | #5849 |
On 5/7/12 5:15 PM, Jerry Stuckle wrote: > On 5/7/2012 6:01 PM, Daniel Pitts wrote: >> On 5/7/12 2:49 PM, Peter H. Coffin wrote: >>> On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote: >>>> Arno Welzel wrote: >>>>> Dominique Ottello, 06.05.2012 19:04: >>>>> >>>>>> Arno Welzel<usenet@arnowelzel.de> ??crivait : >>>>>> >>>>>>> Why do you need 64 bit binaries? >>>>>> Because 32 bit PHP binaries do not work with Apache 64 bit. >>>>> >>>>> Ok - why do you need 64 bit at all for a web server? >>>>> >>>> helps a lot when rescaling images on the fly... >>> >>> Do you really do a lot of that, though? I mean, instead of pre-scaling >>> to a certain set number of sizes. Which seems more generally useful. If >>> you do, there's ways to handle that more rapidly and with less load than >>> the general purpose tools that PHP has wrappers for. EG: VIPS is >>> something like 4 times the speed at rescale than Gmagick. >>> >> I haven't been following this thread, but I'll talk about my personal >> experience with image sizes. >> >> My particular company has a huge catalog of images. Right now, we do >> prescale the images to all the various sizes that might be needed, which >> works alright except that our design department every once in a while >> needs a new size. The amount of time required and effort to back-fill >> the old data is relatively large, and we don't necessarily need every >> size for every image (we just don't know where the images will show up >> eventually). >> >> Dynamic image scaling solves that problem nicely. With caching in place >> of course. > > I've had clients who have the same need. It's pretty simple to scale a > large number of images with a batch file (PHP, BASH, etc.), and proper > naming/cataloging takes care of the rest. Pretty simple if you have a small enough set of images. The processor time that would be needed to resize every last image in our catalog was calculated in months. Making this a distributed task would be necessary, and not entirely easy to do in PHP/BASH. > Who cares if you don't use all of the sizes? Disk space is cheap - much > cheaper than processor time. > Exactly true, but if you scale to sizes you don't need, you indeed use more processor time! Our disk space is definitely not the bottleneck.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2012-05-08 09:11 +0200 |
| Message-ID | <4FA8C712.9040702@arnowelzel.de> |
| In reply to | #5851 |
Daniel Pitts, 08.05.2012 05:37: > On 5/7/12 5:15 PM, Jerry Stuckle wrote: [...] >> I've had clients who have the same need. It's pretty simple to scale a >> large number of images with a batch file (PHP, BASH, etc.), and proper >> naming/cataloging takes care of the rest. > Pretty simple if you have a small enough set of images. The processor > time that would be needed to resize every last image in our catalog was > calculated in months. Making this a distributed task would be necessary, > and not entirely easy to do in PHP/BASH. Months? You have to deal with several million images? Because otherwise its hard to imagine that scaling images to a number of sizes - not print resolutions since these images are only used for a web site - will take *months*. -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-08 08:21 -0400 |
| Message-ID | <job33h$qi2$1@dont-email.me> |
| In reply to | #5851 |
On 5/7/2012 11:37 PM, Daniel Pitts wrote: > On 5/7/12 5:15 PM, Jerry Stuckle wrote: >> On 5/7/2012 6:01 PM, Daniel Pitts wrote: >>> On 5/7/12 2:49 PM, Peter H. Coffin wrote: >>>> On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote: >>>>> Arno Welzel wrote: >>>>>> Dominique Ottello, 06.05.2012 19:04: >>>>>> >>>>>>> Arno Welzel<usenet@arnowelzel.de> ??crivait : >>>>>>> >>>>>>>> Why do you need 64 bit binaries? >>>>>>> Because 32 bit PHP binaries do not work with Apache 64 bit. >>>>>> >>>>>> Ok - why do you need 64 bit at all for a web server? >>>>>> >>>>> helps a lot when rescaling images on the fly... >>>> >>>> Do you really do a lot of that, though? I mean, instead of pre-scaling >>>> to a certain set number of sizes. Which seems more generally useful. If >>>> you do, there's ways to handle that more rapidly and with less load >>>> than >>>> the general purpose tools that PHP has wrappers for. EG: VIPS is >>>> something like 4 times the speed at rescale than Gmagick. >>>> >>> I haven't been following this thread, but I'll talk about my personal >>> experience with image sizes. >>> >>> My particular company has a huge catalog of images. Right now, we do >>> prescale the images to all the various sizes that might be needed, which >>> works alright except that our design department every once in a while >>> needs a new size. The amount of time required and effort to back-fill >>> the old data is relatively large, and we don't necessarily need every >>> size for every image (we just don't know where the images will show up >>> eventually). >>> >>> Dynamic image scaling solves that problem nicely. With caching in place >>> of course. >> >> I've had clients who have the same need. It's pretty simple to scale a >> large number of images with a batch file (PHP, BASH, etc.), and proper >> naming/cataloging takes care of the rest. > Pretty simple if you have a small enough set of images. The processor > time that would be needed to resize every last image in our catalog was > calculated in months. Making this a distributed task would be necessary, > and not entirely easy to do in PHP/BASH. > That does not compute. Repeatedly resizing the images on the fly would then take years. >> Who cares if you don't use all of the sizes? Disk space is cheap - much >> cheaper than processor time. >> > Exactly true, but if you scale to sizes you don't need, you indeed use > more processor time! Our disk space is definitely not the bottleneck. And if you repeatedly rescale the same image to the same size, you're using even more processor time! -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-05-08 11:17 -0700 |
| Message-ID | <Nqdqr.177852$KQ2.83856@newsfe15.iad> |
| In reply to | #5854 |
On 5/8/12 5:21 AM, Jerry Stuckle wrote: > On 5/7/2012 11:37 PM, Daniel Pitts wrote: >> On 5/7/12 5:15 PM, Jerry Stuckle wrote: >>> On 5/7/2012 6:01 PM, Daniel Pitts wrote: >>>> On 5/7/12 2:49 PM, Peter H. Coffin wrote: >>>>> On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote: >>>>>> Arno Welzel wrote: >>>>>>> Dominique Ottello, 06.05.2012 19:04: >>>>>>> >>>>>>>> Arno Welzel<usenet@arnowelzel.de> ??crivait : >>>>>>>> >>>>>>>>> Why do you need 64 bit binaries? >>>>>>>> Because 32 bit PHP binaries do not work with Apache 64 bit. >>>>>>> >>>>>>> Ok - why do you need 64 bit at all for a web server? >>>>>>> >>>>>> helps a lot when rescaling images on the fly... >>>>> >>>>> Do you really do a lot of that, though? I mean, instead of pre-scaling >>>>> to a certain set number of sizes. Which seems more generally >>>>> useful. If >>>>> you do, there's ways to handle that more rapidly and with less load >>>>> than >>>>> the general purpose tools that PHP has wrappers for. EG: VIPS is >>>>> something like 4 times the speed at rescale than Gmagick. >>>>> >>>> I haven't been following this thread, but I'll talk about my personal >>>> experience with image sizes. >>>> >>>> My particular company has a huge catalog of images. Right now, we do >>>> prescale the images to all the various sizes that might be needed, >>>> which >>>> works alright except that our design department every once in a while >>>> needs a new size. The amount of time required and effort to back-fill >>>> the old data is relatively large, and we don't necessarily need every >>>> size for every image (we just don't know where the images will show up >>>> eventually). >>>> >>>> Dynamic image scaling solves that problem nicely. With caching in place >>>> of course. >>> >>> I've had clients who have the same need. It's pretty simple to scale a >>> large number of images with a batch file (PHP, BASH, etc.), and proper >>> naming/cataloging takes care of the rest. >> Pretty simple if you have a small enough set of images. The processor >> time that would be needed to resize every last image in our catalog was >> calculated in months. Making this a distributed task would be necessary, >> and not entirely easy to do in PHP/BASH. >> > > That does not compute. Repeatedly resizing the images on the fly would > then take years. > >>> Who cares if you don't use all of the sizes? Disk space is cheap - much >>> cheaper than processor time. >>> >> Exactly true, but if you scale to sizes you don't need, you indeed use >> more processor time! Our disk space is definitely not the bottleneck. > > And if you repeatedly rescale the same image to the same size, you're > using even more processor time! > Who said repeatedly rescale? The process I've been talking about is more like "lazy" scaling.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-09 09:14 -0400 |
| Message-ID | <jodqj4$14a$1@dont-email.me> |
| In reply to | #5860 |
On 5/8/2012 2:17 PM, Daniel Pitts wrote: > On 5/8/12 5:21 AM, Jerry Stuckle wrote: >> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>> On 5/7/12 5:15 PM, Jerry Stuckle wrote: >>>> On 5/7/2012 6:01 PM, Daniel Pitts wrote: >>>>> On 5/7/12 2:49 PM, Peter H. Coffin wrote: >>>>>> On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote: >>>>>>> Arno Welzel wrote: >>>>>>>> Dominique Ottello, 06.05.2012 19:04: >>>>>>>> >>>>>>>>> Arno Welzel<usenet@arnowelzel.de> ??crivait : >>>>>>>>> >>>>>>>>>> Why do you need 64 bit binaries? >>>>>>>>> Because 32 bit PHP binaries do not work with Apache 64 bit. >>>>>>>> >>>>>>>> Ok - why do you need 64 bit at all for a web server? >>>>>>>> >>>>>>> helps a lot when rescaling images on the fly... >>>>>> >>>>>> Do you really do a lot of that, though? I mean, instead of >>>>>> pre-scaling >>>>>> to a certain set number of sizes. Which seems more generally >>>>>> useful. If >>>>>> you do, there's ways to handle that more rapidly and with less load >>>>>> than >>>>>> the general purpose tools that PHP has wrappers for. EG: VIPS is >>>>>> something like 4 times the speed at rescale than Gmagick. >>>>>> >>>>> I haven't been following this thread, but I'll talk about my personal >>>>> experience with image sizes. >>>>> >>>>> My particular company has a huge catalog of images. Right now, we do >>>>> prescale the images to all the various sizes that might be needed, >>>>> which >>>>> works alright except that our design department every once in a while >>>>> needs a new size. The amount of time required and effort to back-fill >>>>> the old data is relatively large, and we don't necessarily need every >>>>> size for every image (we just don't know where the images will show up >>>>> eventually). >>>>> >>>>> Dynamic image scaling solves that problem nicely. With caching in >>>>> place >>>>> of course. >>>> >>>> I've had clients who have the same need. It's pretty simple to scale a >>>> large number of images with a batch file (PHP, BASH, etc.), and proper >>>> naming/cataloging takes care of the rest. >>> Pretty simple if you have a small enough set of images. The processor >>> time that would be needed to resize every last image in our catalog was >>> calculated in months. Making this a distributed task would be necessary, >>> and not entirely easy to do in PHP/BASH. >>> >> >> That does not compute. Repeatedly resizing the images on the fly would >> then take years. >> >>>> Who cares if you don't use all of the sizes? Disk space is cheap - much >>>> cheaper than processor time. >>>> >>> Exactly true, but if you scale to sizes you don't need, you indeed use >>> more processor time! Our disk space is definitely not the bottleneck. >> >> And if you repeatedly rescale the same image to the same size, you're >> using even more processor time! >> > Who said repeatedly rescale? The process I've been talking about is more > like "lazy" scaling. OK, so you do it "on the fly" and store the result. That still takes more time than doing it once and forgetting it. Your way, you have to check on every request for the image to see if your size exists before deciding if you need to rescale it or not. Another unnecessary waste of processing time. And you still haven't answered the question as to why it would take months to rescale your images. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Gregor Kofler <usenet@gregorkofler.com> |
|---|---|
| Date | 2012-05-09 17:05 +0200 |
| Message-ID | <joe142$9fl$1@dont-email.me> |
| In reply to | #5875 |
Am 2012-05-09 15:14, Jerry Stuckle meinte: >> Who said repeatedly rescale? The process I've been talking about is more >> like "lazy" scaling. > > OK, so you do it "on the fly" and store the result. That still takes > more time than doing it once and forgetting it. Your way, you have to > check on every request for the image to see if your size exists before > deciding if you need to rescale it or not. Another unnecessary waste of > processing time. Please... Having a page with a bunch of images uploaded by users in various (normally large) sizes the scaling on the fly takes the proverbial ages (i.e. several seconds). Particularly on shared hosts. Checking for the existence of a file (you know the output size and you changed the file name of you rescaled images accordingly) is negligible. Rescaling happens once, retrieving thousands of times (or more). > And you still haven't answered the question as to why it would take > months to rescale your images. Indeed. Gregor
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-09 12:21 -0400 |
| Message-ID | <joe5ih$5t7$1@dont-email.me> |
| In reply to | #5884 |
On 5/9/2012 11:05 AM, Gregor Kofler wrote: > Am 2012-05-09 15:14, Jerry Stuckle meinte: > >>> Who said repeatedly rescale? The process I've been talking about is more >>> like "lazy" scaling. >> >> OK, so you do it "on the fly" and store the result. That still takes >> more time than doing it once and forgetting it. Your way, you have to >> check on every request for the image to see if your size exists before >> deciding if you need to rescale it or not. Another unnecessary waste of >> processing time. > > Please... Having a page with a bunch of images uploaded by users in > various (normally large) sizes the scaling on the fly takes the > proverbial ages (i.e. several seconds). Particularly on shared hosts. > Checking for the existence of a file (you know the output size and you > changed the file name of you rescaled images accordingly) is negligible. > Rescaling happens once, retrieving thousands of times (or more). > >> And you still haven't answered the question as to why it would take >> months to rescale your images. > > Indeed. > > Gregor > So it takes a few seconds to do it once? It's going to take the same total amount of time to do the scaling later, and you skip the overhead of needlessly checking to see if the image exists "thousands of times (or more)". -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-09 19:36 +0100 |
| Message-ID | <joedfh$419$8@news.albasani.net> |
| In reply to | #5884 |
Gregor Kofler wrote: > Am 2012-05-09 15:14, Jerry Stuckle meinte: > >>> Who said repeatedly rescale? The process I've been talking about is more >>> like "lazy" scaling. >> >> OK, so you do it "on the fly" and store the result. That still takes >> more time than doing it once and forgetting it. Your way, you have to >> check on every request for the image to see if your size exists before >> deciding if you need to rescale it or not. Another unnecessary waste of >> processing time. > > Please... Having a page with a bunch of images uploaded by users in > various (normally large) sizes the scaling on the fly takes the > proverbial ages (i.e. several seconds). No it doesnt. > Particularly on shared hosts. well I cant answer for crap hosts. > Checking for the existence of a file (you know the output size and you > changed the file name of you rescaled images accordingly) is negligible. > Rescaling happens once, retrieving thousands of times (or more). Often never used again. > >> And you still haven't answered the question as to why it would take >> months to rescale your images. > > Indeed. > > Gregor > -- To people who know nothing, anything is possible. To people who know too much, it is a sad fact that they know how little is really possible - and how hard it is to achieve it.
[toc] | [prev] | [next] | [standalone]
| From | Gregor Kofler <usenet@gregorkofler.com> |
|---|---|
| Date | 2012-05-09 21:31 +0200 |
| Message-ID | <joegn4$hou$1@dont-email.me> |
| In reply to | #5895 |
Am 2012-05-09 20:36, The Natural Philosopher meinte: > Gregor Kofler wrote: >> Am 2012-05-09 15:14, Jerry Stuckle meinte: >> >>>> Who said repeatedly rescale? The process I've been talking about is >>>> more >>>> like "lazy" scaling. >>> >>> OK, so you do it "on the fly" and store the result. That still takes >>> more time than doing it once and forgetting it. Your way, you have to >>> check on every request for the image to see if your size exists before >>> deciding if you need to rescale it or not. Another unnecessary waste of >>> processing time. >> >> Please... Having a page with a bunch of images uploaded by users in >> various (normally large) sizes the scaling on the fly takes the >> proverbial ages (i.e. several seconds). > > No it doesnt. It does. People tend to upload their images straight as they come from their camera/smartphone. And I need them as 300x200 thumbs and in an enlarged 900x600 something format. Perhaps sharpened. >> Particularly on shared hosts. > > well I cant answer for crap hosts. Frequently not something the developer can decide. > >> Checking for the existence of a file (you know the output size and you >> changed the file name of you rescaled images accordingly) is negligible. >> Rescaling happens once, retrieving thousands of times (or more). > > Often never used again. They lookup and/or rescaling happens, when an image is displayed. Not before. You do the rescaling when it is required, and then you do it only once. IOW the one-time-storing and the frequent checking for file existence replaces the frequent on-the-fly resizing. No way, that the latter one is faster (I do websites which are visited by more than one person - hopefully). Gregor
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.php
csiph-web