FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.
Home » Imported messages » comp.lang.php » Re: Windows binaries 64bit for PHP
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: Windows binaries 64bit for PHP [message #178037 is a reply to message #178036] Fri, 11 May 2012 02:22 Go to previous messageGo to previous message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
Senior Member
On 5/10/2012 9:50 PM, Daniel Pitts wrote:
> On 5/10/12 4:35 PM, Jerry Stuckle wrote:
>> On 5/10/2012 5:29 PM, Daniel Pitts wrote:
>>> On 5/10/12 2:05 PM, Jerry Stuckle wrote:
>>>> On 5/10/2012 4:15 PM, Daniel Pitts wrote:
>>>> > On 5/9/12 8:53 PM, Jerry Stuckle wrote:
>>>> >> On 5/9/2012 6:28 PM, Daniel Pitts wrote:
>>>> >>> On 5/9/12 3:19 PM, Michael Fesser wrote:
>>>> >>>> .oO(Jerry Stuckle)
>>>> >>>>
>>>> >>>>> On 5/8/2012 4:25 PM, 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.
>>>> >>>>>
>>>> >>>>> No, I didn't. By definition, caching is temporary storage which
>>>> >>>>> can be
>>>> >>>>> erased at any time.
>>>> >>>>
>>>> >>>> Correct. And then the rescaled images are created again when
>>>> >>>> needed, so
>>>> >>>> what's the problem? It all happens automatically.
>>>> >>>>
>>>> >>>> Micha
>>>> >>>>
>>>> >>>
>>>> >>> Caching needn't be temporary, and you can ensure it isn't "erased at
>>>> >>> any
>>>> >>> time" by just not erasing the "cache". There are many different
>>>> >>> types of
>>>> >>> "cache".
>>>> >>
>>>> >> By definition a cache is temporary.
>>>> >>
>>>> > Whose definition?
>>>> > According to <http://www.thefreedictionary.com/cache>
>>>> >
>>>> > 1. "A collection of items of the same type stored in a hidden or
>>>> > inaccessible place."
>>>> > 2. Computer Science: A fast storage buffer in the central processing
>>>> > unit of a computer. Also called cache memory.
>>>> >
>>>> > That doesn't define it as temporary. Perhaps you're mistaking your
>>>> > understanding of the concept with reality. Reality wins over your
>>>> > understanding.
>>>> >
>>>> > Anyway, I've had enough fun arguing with an obvious "expert" in this
>>>> > field. Enjoy being "right" on the internet.
>>>> >
>>>> > Good day,
>>>> > Daniel.
>>>>
>>>> And you obviously don't understand what you're reading.
>>>>
>>>> Since when is "memory" permanent? I thought that's why we had hard
>>>> drives. And I don't see any thing in your definition about hard drives.
>>>>
>>> So, lets take a step back here.
>>>
>>> Forget the word caching, and your misunderstanding of it altogether.
>>>
>>> A system which will resize an image on-demand, and store the resize
>>> image for later retrieval is more efficient than one that will create
>>> all known previous sizes and then reprocessing all old images as new
>>> requirements are introduced.
>>>
>>>
>>
>> I do not misunderstand caching. Just because YOU have no idea what
>> you're talking about doesn't mean anyone else doesn't.
> I have some idea, as I actually work on such a system. You seem to have
> little real-world experience, as you seem to think that one solution
> suits all

I have over 40 years of "real world experience", including 13 with IBM
and 22 as a consultant. I suspect I was programming before you were born.

>>
>> And a system which creates all the images once so it doesn't have to
>> keep needlessly checking to see if an image exists or not is more
>> efficient than one which constantly has to see if something exists or
>> not.
> Whatever is serving your static content must check if it exists or not.
> You can hook into the "or-not" case, which happens only once per image
> per size that is *actually* used.

It's a simple file load from Apache. No additional application
programming required. And, being a compiled program, it's quite fast.

With your way, Apache has to load a PHP script (same process as I just
referenced). But then it has to start call the PHP module to establish
the PHP environment, interpret the script, execute the script, which
then has to check to see if the file exists or not. Much more
processing than above, and it has to be done on every request.

Or, let Apache try to load the file. If the load fails, call the 404
error handler (more overhead) which then has to go through all the
processing to load an execute a PHP file (as noted above) then resizing
the image.

Either way there is significantly more overhead than resizing once and
forgetting it. But you don't seem to understand that.

>>
>> Resizing is done ONCE. Checking has to be done on EVERY REQUEST.
> Checking has to be done on every request regardless. This is not an
> extra step.
>

See above. If the file exists, Apache can handle it directly.

>> But then you're got your mind made up. After all, it would take "months"
>> for you to resize your images.
> Months may have been a slight exaggeration, but it does take more than a
> few days to resize every possible image.
>

Even days is an exaggeration if you get rid of your TRS-80. You
obviously have NO IDEA how long anything would take. You're just
guessing (again).

>> A good system can resize several hundred images a second. At most we're
>> taking a few hours to do 7.5M images, even if they are high-res. But
>> your TRS-80's may only be able to do one a second.
> It is still easier to set up this lazy-loading once, than to have to run
> a "few hours" of scripts every time requirements change. The site will
> perform well enough (storing the resized images permanently, plus having
> edge cache in front of them). Why waste an engineers time running such a
> script (which is more expensive than CPU time needed to handle the lazy
> resizing).
>

You've got it. It's easier to set up the lazy-loading. It takes actual
skill to be able to write a script which will resize all the images for you.

> The actual hardware in question is a "Compaq DL385 G6"
>
> CPU: 12 x 2200 MHz Six-Core AMD Opteron 2427, 512 KB cache
> Memory: 64461MB
>
> Granted, this machine is shared with many other tools.
>

If that actually were your system, then it should take nowhere near 12
days to process 7.5M images. But you don't know - you're still guessing
because you don't have the skills to figure out how to resize the images
from a script.

But we know all you've got is your trusty TRS-80.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: is_dir true from cli, false from Apache
Next Topic: in_array performance in unsorted vs sorted array
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Tue Nov 26 21:39:42 GMT 2024

Total time taken to generate the page: 0.05614 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.1.3.
Copyright ©2001-2023 FUDforum Bulletin Board Software