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 #178057 is a reply to message #178037] Fri, 11 May 2012 17:03 Go to previous messageGo to previous message
Daniel Pitts is currently offline  Daniel Pitts
Messages: 68
Registered: May 2012
Karma:
Member
On 5/10/12 7:22 PM, Jerry Stuckle wrote:
> 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.
Ad hominem attacks huh? You have no idea of my skill level, and have yet
to prove yours.

I did a little digging into the history of this newsgroup. I didn't
realize you were the resident troll, and was trying to use reason with
you. It's been fun sparing with you, but you have proven to me that you
have no interest in facts and reason.

*plonk*

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: Sun Nov 03 12:33:17 GMT 2024

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

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