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 #178036 is a reply to message #178033] Fri, 11 May 2012 01:50 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 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.
>
> 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.
>
> 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.

> 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.

> 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).

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.

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: Sat Nov 30 04:25:11 GMT 2024

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

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