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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-05-12 11:12 +0200 |
| Message-ID | <1401847.AFRqVoOGUt@PointedEars.de> |
| In reply to | #5896 |
Gregor Kofler wrote:
> 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. […]
People need to be educated not to do that. High-resolution images with huge
dimensions result in large files. There is already a limitation in the
upload file size (upload_max_filesize), and that is good so. You can make
allowances and do not have to stick to the default 2M maximum, but allowing
people to upload files of *any* size to a server is virtual(ly) suicide. So
that is not a very convincing argument in favor of 64-bit processing.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-12 22:56 +0100 |
| Message-ID | <jommaj$rt7$2@news.albasani.net> |
| In reply to | #5991 |
Thomas 'PointedEars' Lahn wrote: > > People need to be educated not to do that. It has been said that socialists know how the world should be, but conservatives understand how it actually is. -- 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 | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2012-05-14 10:51 +0200 |
| Message-ID | <4fb0c781$0$6963$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #6000 |
On 5/12/2012 11:56 PM, The Natural Philosopher wrote: > Thomas 'PointedEars' Lahn wrote: > >> >> People need to be educated not to do that. > > It has been said that socialists know how the world should be, but > conservatives understand how it actually is. > AND want to keep it that way. ;-) Regards, Erwin Moller -- "That which can be asserted without evidence, can be dismissed without evidence." -- Christopher Hitchens
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-14 10:17 +0100 |
| Message-ID | <joqik7$uge$1@news.albasani.net> |
| In reply to | #6019 |
Erwin Moller wrote: > On 5/12/2012 11:56 PM, The Natural Philosopher wrote: >> Thomas 'PointedEars' Lahn wrote: >> >>> >>> People need to be educated not to do that. >> >> It has been said that socialists know how the world should be, but >> conservatives understand how it actually is. >> > > AND want to keep it that way. ;-) > NOT necessarily... But they tend to restrict themselves to what is achievable, and expect that it wont be cost free! > Regards, > Erwin Moller > > -- 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-14 19:26 +0200 |
| Message-ID | <jorf7n$e9s$1@dont-email.me> |
| In reply to | #5991 |
Am 2012-05-12 11:12, Thomas 'PointedEars' Lahn meinte: > Gregor Kofler wrote: > >> 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. […] > > People need to be educated not to do that. I try to. As far as filesize restrictions are concerned: 12 megapixels from low-quality devices are frequently "small enough". Gregor
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-10 00:23 +0200 |
| Message-ID | <0drlq7t8h16rd6jrovjh4sbl21t33t8121@mfesser.de> |
| In reply to | #5875 |
.oO(Jerry Stuckle) >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. You can catch that with Apache's error handling. If the image is not found, the 404 error handler kicks in and creates it. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-09 23:52 -0400 |
| Message-ID | <jofe21$iin$1@dont-email.me> |
| In reply to | #5900 |
On 5/9/2012 6:23 PM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> 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. > > You can catch that with Apache's error handling. If the image is not > found, the 404 error handler kicks in and creates it. > > Micha > Which is even more overhead... -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-10 08:50 +0200 |
| Message-ID | <r7pmq7h4ge5v4hr0v0s3mtfvea57cikb1r@mfesser.de> |
| In reply to | #5905 |
.oO(Jerry Stuckle) >On 5/9/2012 6:23 PM, Michael Fesser wrote: >> .oO(Jerry Stuckle) >> >>> 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. >> >> You can catch that with Apache's error handling. If the image is not >> found, the 404 error handler kicks in and creates it. >> >> Micha >> > >Which is even more overhead... Wrong. The little overhead happens just once if the image doesn't exist yet. After then it's just a static resource, which will be delivered directly by the server. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-10 08:01 -0400 |
| Message-ID | <jogam3$r8j$1@dont-email.me> |
| In reply to | #5910 |
On 5/10/2012 2:50 AM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/9/2012 6:23 PM, Michael Fesser wrote: >>> .oO(Jerry Stuckle) >>> >>>> 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. >>> >>> You can catch that with Apache's error handling. If the image is not >>> found, the 404 error handler kicks in and creates it. >>> >>> Micha >>> >> >> Which is even more overhead... > > Wrong. The little overhead happens just once if the image doesn't exist > yet. After then it's just a static resource, which will be delivered > directly by the server. > > Micha > Have you actually checked how much overhead there is to process a not found? It is quite significant. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-10 21:01 +0200 |
| Message-ID | <el3oq7pgrnlflko978ke7ibuapfsdesj10@mfesser.de> |
| In reply to | #5911 |
.oO(Jerry Stuckle) >On 5/10/2012 2:50 AM, Michael Fesser wrote: >> .oO(Jerry Stuckle) >> >>> On 5/9/2012 6:23 PM, Michael Fesser wrote: >>>> .oO(Jerry Stuckle) >>>> >>>>> 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. >>>> >>>> You can catch that with Apache's error handling. If the image is not >>>> found, the 404 error handler kicks in and creates it. >>>> >>>> Micha >>>> >>> >>> Which is even more overhead... >> >> Wrong. The little overhead happens just once if the image doesn't exist >> yet. After then it's just a static resource, which will be delivered >> directly by the server. > >Have you actually checked how much overhead there is to process a not >found? It is quite significant. Even if - how often does it happen? Exactly once for every image. So where's the problem? In many other cases the first request causes a lot of overhead as well, be it the initial compiling of a PHP script or the downloading of a static resource to the client. The first request always takes the most time. After then the data is taken from some kind of cache. And here it's exactly the same - on the first request the image is created, after then it's a normal static resource. In practice there's absolutely no problem with that and no wasted CPU time. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-10 15:12 -0400 |
| Message-ID | <joh3v7$159$1@dont-email.me> |
| In reply to | #5931 |
On 5/10/2012 3:01 PM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/10/2012 2:50 AM, Michael Fesser wrote: >>> .oO(Jerry Stuckle) >>> >>>> On 5/9/2012 6:23 PM, Michael Fesser wrote: >>>>> .oO(Jerry Stuckle) >>>>> >>>>>> 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. >>>>> >>>>> You can catch that with Apache's error handling. If the image is not >>>>> found, the 404 error handler kicks in and creates it. >>>>> >>>>> Micha >>>>> >>>> >>>> Which is even more overhead... >>> >>> Wrong. The little overhead happens just once if the image doesn't exist >>> yet. After then it's just a static resource, which will be delivered >>> directly by the server. >> >> Have you actually checked how much overhead there is to process a not >> found? It is quite significant. > > Even if - how often does it happen? Exactly once for every image. So > where's the problem? > > In many other cases the first request causes a lot of overhead as well, > be it the initial compiling of a PHP script or the downloading of a > static resource to the client. The first request always takes the most > time. After then the data is taken from some kind of cache. And here > it's exactly the same - on the first request the image is created, after > then it's a normal static resource. In practice there's absolutely no > problem with that and no wasted CPU time. > > Micha > And when you create the images one time, it's done ZERO times. And no, the data isn't always taken from some kind of cache. It depends on a lot of things. For instance, a PHP script is compiled every time it's called unless the server can determine nothing has changed (generally not the case) or you have installed additional PHP caching software. Web servers do not cache compiled code, and neither does the PHP module by itself. Back to the subject at hand - every time the system has to handle a 404 there is wasted time. And it is a relatively significant amount of time. Adding the necessity of resizing an image to that can be costly on a busy server. Of course, if all you get are 200 hits/day, it doesn't make any difference how you code your scripts. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-11 11:56 +0200 |
| Message-ID | <ogopq7hreqccf03i2n25p471tn2kdma1oe@mfesser.de> |
| In reply to | #5933 |
.oO(Jerry Stuckle) >Back to the subject at hand - every time the system has to handle a 404 >there is wasted time. And it is a relatively significant amount of >time. After the image has been created, there won't be any 404s anymore. There will be just _one_ per image to trigger the rescaling. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-11 06:50 -0400 |
| Message-ID | <joiqte$q7t$1@dont-email.me> |
| In reply to | #5954 |
On 5/11/2012 5:56 AM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> Back to the subject at hand - every time the system has to handle a 404 >> there is wasted time. And it is a relatively significant amount of >> time. > > After the image has been created, there won't be any 404s anymore. There > will be just _one_ per image to trigger the rescaling. > > Micha > Yup, and with the 7.5M that images he claims he has, that's a lot of wasted CPU. -- ================== 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-11 13:57 +0100 |
| Message-ID | <joj2ce$pqq$5@news.albasani.net> |
| In reply to | #5954 |
Michael Fesser wrote: > .oO(Jerry Stuckle) > >> Back to the subject at hand - every time the system has to handle a 404 >> there is wasted time. And it is a relatively significant amount of >> time. > > After the image has been created, there won't be any 404s anymore. There > will be just _one_ per image to trigger the rescaling. > you don't even have to have a 404. Use a php script to either load and send the scaled page, or load rescale send and STORE the page. > Micha > -- 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-11 10:29 -0400 |
| Message-ID | <joj7oc$4fh$1@dont-email.me> |
| In reply to | #5960 |
On 5/11/2012 8:57 AM, The Natural Philosopher wrote: > Michael Fesser wrote: >> .oO(Jerry Stuckle) >> >>> Back to the subject at hand - every time the system has to handle a >>> 404 there is wasted time. And it is a relatively significant amount >>> of time. >> >> After the image has been created, there won't be any 404s anymore. There >> will be just _one_ per image to trigger the rescaling. >> > > you don't even have to have a 404. Use a php script to either load and > send the scaled page, or load rescale send and STORE the page. > > >> Micha >> > > Which is even more processing! -- ================== 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-11 13:32 -0500 |
| Message-ID | <slrnjqqmpd.4ci.hellsop@nibelheim.ninehells.com> |
| In reply to | #5960 |
On Fri, 11 May 2012 13:57:50 +0100, The Natural Philosopher wrote: > Michael Fesser wrote: >> .oO(Jerry Stuckle) >> >>> Back to the subject at hand - every time the system has to handle a 404 >>> there is wasted time. And it is a relatively significant amount of >>> time. >> >> After the image has been created, there won't be any 404s anymore. There >> will be just _one_ per image to trigger the rescaling. >> > > you don't even have to have a 404. Use a php script to either load and > send the scaled page, or load rescale send and STORE the page. I love it. (: OP's already resisted a proper build/rollout process as an option anyway, let's build something that combines the *worst* of both options... -- "Every new technology carries with it an opportunity to invent a new crime." --Laurence Urgenson (an assistant chief US attorney), speaking in 1987 about the first arrests for what was later called cellphone cloning.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-11 20:01 +0100 |
| Message-ID | <jojnmb$94h$1@news.albasani.net> |
| In reply to | #5970 |
Peter H. Coffin wrote: > On Fri, 11 May 2012 13:57:50 +0100, The Natural Philosopher wrote: >> Michael Fesser wrote: >>> .oO(Jerry Stuckle) >>> >>>> Back to the subject at hand - every time the system has to handle a 404 >>>> there is wasted time. And it is a relatively significant amount of >>>> time. >>> After the image has been created, there won't be any 404s anymore. There >>> will be just _one_ per image to trigger the rescaling. >>> >> you don't even have to have a 404. Use a php script to either load and >> send the scaled page, or load rescale send and STORE the page. > > I love it. (: OP's already resisted a proper build/rollout process as an > option anyway, let's build something that combines the *worst* of both > options... > not if you like your pikkies in a database... -- 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 | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-08 22:25 +0200 |
| Message-ID | <370jq7t07vrqpqn8l94rbpgcb4vmifma0q@mfesser.de> |
| In reply to | #5854 |
.oO(Jerry Stuckle) >On 5/7/2012 11:37 PM, Daniel Pitts wrote: >> 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! You missed the word 'caching'. You rescale when needed, and only once. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | "Peter H. Coffin" <hellsop@ninehells.com> |
|---|---|
| Date | 2012-05-08 21:29 -0500 |
| Message-ID | <slrnjqjlko.4ci.hellsop@nibelheim.ninehells.com> |
| In reply to | #5861 |
On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>>On 5/7/2012 11:37 PM, Daniel Pitts wrote:
>>> 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!
>
> You missed the word 'caching'. You rescale when needed, and only once.
How is this different than pre-scaling the images?
--
Compared to system administration, being cursed forever is a step up.
-- Paul Tomko
[toc] | [prev] | [next] | [standalone]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2012-05-09 09:56 +0200 |
| Message-ID | <4faa2335$0$6947$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #5864 |
On 5/9/2012 4:29 AM, Peter H. Coffin wrote: > On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote: >> .oO(Jerry Stuckle) >> >>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>> 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! >> >> You missed the word 'caching'. You rescale when needed, and only once. > > How is this different than pre-scaling the images? > Hi Peter, It is different because they are *only* rescaled when not found. One approach I used: 1) Need image xyz_2012_march_nr12_300x500.jpg (The 300x500 is dimensions needed.) 2) Check if it exists. If not: Create it out of original (xyz_2012_march_nr12.jpg in this case) and store it. One can easily wrap this functionality in a function. So the difference is that you don't need a batchjob that apparently needs months and that will resize many images that are never needed, or never needed on that size. (I have my doubts about the alleged months, but that doesn't matter.) Regards, Erwin Moller -- "That which can be asserted without evidence, can be dismissed without evidence." -- Christopher Hitchens
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.php
csiph-web