php-general Digest 29 Nov 2010 09:37:04 -0000 Issue 7060
Topics (messages 309736 through 309742):
Re: I have a question about MLM
309736 by: Daniel P. Brown
Re: preg_match fails to resolve variable as a subject
309737 by: Richard Quadling
Re: Problem with RegEx for BBCode
309738 by: Richard Quadling
Disk IO performance
309739 by: Larry Garfield
309740 by: Andrew Mason
309741 by: Per Jessen
309742 by: Daniel Molina Wegener
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
On Sun, Nov 28, 2010 at 15:54, Tommy Pham <[email protected]> wrote:
>
> Which MLM are you referring you? ;) Multi-Level Marketing? Mid-Level
> Manager? Medicare Learning Network? Marxism-Leninism-Maoism?
It's likely SPAM-testing or email harvesting. The exact same
vague email was sent to the php-db@ list during the same minute. I'd
ignore it, and if the OP wants a real response, he can try again in a
more intelligent form.
--
</Daniel P. Brown>
Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting
(866-) 725-4321
http://www.parasane.net/
--- End Message ---
--- Begin Message ---
On 27 November 2010 04:45, Da Rock <[email protected]> wrote:
> On 11/27/10 13:51, Tamara Temple wrote:
>>
>> On Nov 26, 2010, at 7:28 PM, Da Rock wrote:
>>
>>> On 11/27/10 00:57, Richard Quadling wrote:
>>>>
>>>> On 26 November 2010 00:07, Da Rock<[email protected]>
>>>> wrote:
>>>>
>>>>> preg_match("/(\d{1,3})(\.)$/", exec($mixer . ' ' . $command),&$matches)
>>>>>
>>>> Can you ...
>>>>
>>>> var_dump(exec($mixer . ' ' . $command));
>>>>
>>>> I wonder if the output includes a new line which you are not
>>>> accounting for in the regex.
>>>>
>>>>
>>> Haven't tried yet, but isn't that what $ is for? End of line?
>>>
>>
>>
>> $ matches end of line, but since your last match expression is to match
>> explicitly the character '.' before end of line, and there's a newline, it
>> won't match. Again, use trim() to get rid of the newline character at the
>> end of the string returned by exec(). Looking at the output or
>>
>>> And exec only gives one line- the last line of the output of the command.
>>> You have to provide a reference to an array for the entire output.
>>>
>>> var_dump gives:
>>> string(41) "Mixer vol is currently set to 75:75"
>>>
>>
>> It also looks like \d{1,3}\. won't match anything in the output string
>> given by the command.
>>
>>
>>
> Thank you for that- that did it. I removed the \.
>
> I am a little confused though; that regex was tested on several test sites
> and was deemed accurate on them, and one of them actually supplied the
> preg_match code. And if I run the command on a shell it actually outputs
> exactly the right subject for the regex- not to mention it got printed
> inadvertently (using system() ) via the php exactly the same. So I don't
> think I missed it somehow.
>
> What I have constantly seen come up (shell and php/html) is: Mixer vol is
> currently set to 75:75. (including the period)
>
> Don't get me wrong- you guys make sense; my system doesn't. I need to get to
> the bottom of this so I can ensure my code will port well. I don't want to
> get it all working and find it breaks when I run it on another system,
> albeit same OS (FreeBSD). Could be updates or variations of releases.
>
> Just to check again, I ran the command on the shell again and sure enough
> the period is no longer there- but I can't for the life of me figure out
> when that changed as this code has never worked (and yes, I added in the \.
> to match the end of line because it originally wasn't working). Another
> great mystery? Weird... :)
>
> Thanks again guys.
The regex is a valid regex. It's just useless for the data you are providing it.
I'm wondering what is missing from your output? The var_dump says the
text is a 41 character string, but the data you provided only has 36
characters in it.
What elements of the string do you want to capture?
/:(\d++)/ would catch the number after the :
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
On 27 November 2010 13:57, Asmann, Roland <[email protected]> wrote:
> Hi all,
>
> I am playing around with PHP and BBCodes and have found some regex's
> that should transform my BBCode into correct HTML when rendering.
> However, I have found that if the BBCode is not correct (eg missing
> closing tag), the regex completely eats my input and my page is empty!
>
> The regex I'm using is:
> /\[i\]((\s|.)+?)\[\/i\]/
>
> And with an input like:
> This is [i]italic.
>
> I get nothing back.
>
> What I would like is that when no closing tag is found, the opening tag
> should just be shown as-is. Anybody have any idea how I can do this?
>
> Thanks!
>
> --
> Roland Asmann
> Senior Software Engineer
>
> adesso Austria GmbH
> Floridotower 26. Stock T +43 1 2198790-27
> Floridsdorfer Hauptstr. 1 F +43 1 2198790-927
> A-1210 Wien M +43 664 88657566
> E [email protected]
> W www.adesso.at
>
> -------------------------------------------------------------
> >>> business. people. technology. <<<
> -------------------------------------------------------------
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I think this is a common issue with regex. Trying to use Regex as a
parser is no good. At best, regex can be used as a tokenizer. It has
limited ability to handle the nesting.
The input you gave has no closing [/i], so the regex can't match the
string, so nothing is returned.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
There are many things that everybody "knows" about optimizing PHP code. One
of them is that one of the most expensive parts of the process is loading code
off of disk and compiling it, which is why opcode caches are such a bit
performance boost. The corollary to that, of course, is that more files =
more IO and therefore more of a performance hit.
But... this is 'effin 2010. It's almost bloody 2011. Operating systems are
smart. They already have 14 levels of caching built into them from hard drive
micro-controller to RAM to CPU cache to OS. I've heard from other people (who
should know) that the IO cost of doing a file_exists() or other stat calls is
almost non-existent because a modern OS caches that, and with OS-based file
caching even reading small files off disk (the size that most PHP source files
are) is not as slow as we think.
Personally, I don't know. I am not an OS engineer and haven't benchmarked
such things, nor am I really competent to do so. However, it makes a huge
impact on the way one structures a large PHP program as the performance trade-
offs of huge files with massive unused code (that has to be compiled) vs the
cost of reading lots of separate files from disk (more IO) is highly dependent
on the speed of the aforementioned IO and of compilation.
So... does anyone have any actual, hard data here? I don't mean "I think" or
"in my experience". I am looking for hard benchmarks, profiling, or writeups
of how OS (Linux specifically if it matters) file caching works in 2010, not
in 1998.
Modernizing what "everyone knows" is important for the general community, and
the quality of our code.
--Larry Garfield
--- End Message ---
--- Begin Message ---
On Mon, Nov 29, 2010 at 12:09 PM, Larry Garfield <[email protected]> wrote:
> There are many things that everybody "knows" about optimizing PHP code. One
> of them is that one of the most expensive parts of the process is loading code
> off of disk and compiling it, which is why opcode caches are such a bit
> performance boost. The corollary to that, of course, is that more files =
> more IO and therefore more of a performance hit.
I'd just organise them how you think makes most sense and then
optimize if you run into issues.
Kind regards
Andrew M
--- End Message ---
--- Begin Message ---
Larry Garfield wrote:
> There are many things that everybody "knows" about optimizing PHP
> code. One of them is that one of the most expensive parts of the
> process is loading code off of disk and compiling it, which is why
> opcode caches are such a bit performance boost. The corollary to
> that, of course, is that more files = more IO and therefore more of a
> performance hit.
[snip]
> So... does anyone have any actual, hard data here? I don't mean "I
> think" or "in my experience". I am looking for hard benchmarks,
> profiling, or writeups of how OS (Linux specifically if it matters)
> file caching works in 2010, not in 1998.
The principle hasn't changed since the 50s - read the file into memory,
and keep it there (and keep reading it from there) as long as it isn't
written to. The implementation has changed many times over, but it's
not something we as regular application programmers ought to be much
converned with. Leave it to the smart operating system.
--
Per Jessen, Zürich (1.6°C)
--- End Message ---
--- Begin Message ---
On Sunday 28 November 2010,
Larry Garfield <[email protected]> wrote:
> There are many things that everybody "knows" about optimizing PHP code.
> One of them is that one of the most expensive parts of the process is
> loading code off of disk and compiling it, which is why opcode caches
> are such a bit performance boost. The corollary to that, of course, is
> that more files = more IO and therefore more of a performance hit.
It depends on the implementation that PHP uses to open the file. For
example on Linux and similar operating systems, PHP uses the mmap(2)
function instead of read(2) or fread(2) functions, so it maps the complete
file into memory, that is more faster than using partial file reads.
>
> But... this is 'effin 2010. It's almost bloody 2011. Operating systems
> are smart. They already have 14 levels of caching built into them from
> hard drive micro-controller to RAM to CPU cache to OS. I've heard from
> other people (who should know) that the IO cost of doing a file_exists()
> or other stat calls is almost non-existent because a modern OS caches
> that, and with OS-based file caching even reading small files off disk
> (the size that most PHP source files are) is not as slow as we think.
Yes, that's true. This point depends on how the operating system has
implemented it's VFS. Linux, FreeBSD and other platforms, have a well
done implementation of VFSs, so they have a good cache implementation
for concurrent reads, and first read on a file is made /hard/, then it
uses the cached file location (inode data).
>
> Personally, I don't know. I am not an OS engineer and haven't
> benchmarked such things, nor am I really competent to do so. However,
> it makes a huge impact on the way one structures a large PHP program as
> the performance trade- offs of huge files with massive unused code (that
> has to be compiled) vs the cost of reading lots of separate files from
> disk (more IO) is highly dependent on the speed of the aforementioned IO
> and of compilation.
You can do your own benchmarks tests, from high level perspective or
low level perspective. If you want to trace performance on how PHP reads
files from the hard drive, you can use some extensions like xdebug.
For example if you prefer to use require() and include(), instead of
require_once() and include_once() for concurrent reads, probably you
will get a lower performance because you will do real concurrent reads
on certain files.
>
> So... does anyone have any actual, hard data here? I don't mean "I
> think" or "in my experience". I am looking for hard benchmarks,
> profiling, or writeups of how OS (Linux specifically if it matters) file
> caching works in 2010, not in 1998.
Well, it also depends on the operating system configuration. If you
just want to know the performance of IO functions on PHP, I suggest to
use an extension like xdebug. It can generate profiling information to
be used with kcachegrind, so you can properly visualize how are working
IO functions in php.
Probably a mmap(2) extension for PHP would be useful for certain kind
of files. The file_get_contents() function uses open(2)/read(2), so you
can't do a quick on a file.
>
> Modernizing what "everyone knows" is important for the general community,
> and the quality of our code.
>
> --Larry Garfield
Best regards,
--
Daniel Molina Wegener <dmw [at] coder [dot] cl>
System Programmer & Web Developer
Phone: +56 (2) 979-0277 | Blog: http://coder.cl/
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
