PHP Read Text File

[tlpell]

Hey, read some tips/pointers on PHP.net but can't seem to solve this
problem. I have a php page that reads the contents of a file and then
displays the last XX lines of the file. Problem is this...whenever
the file gets larger that ~5MB, the page just displays nothing, as
though a timeout has occurred but I get no error. At 4.8MB (last
confirmed size)...the function still works. Any ideas what code below
is lacking??

<?
$handle= fopen("/var/log/myfile", "r");
if ($handle) {
while (!feof($handle) ) {
$arrLog[] = fgets($handle, 4096);
}
fclose($handle) ;
}

$int_number_of_ lines = count($arrLog);
if ($int_number_of _lines == 0)
{
echo '<p><strong>No lines read.</strong></p>';
}
if ($int_number_of _lines < $int_lines)
{
$int_lines = $int_number_of_ lines;
}
$int_firstline = $int_number_of_ lines - $int_lines;
echo 'Showing the last '.$int_lines.' lines out of '.
$int_number_of_ lines.'<BR />';
echo "<TABLE WIDTH=100% CLASS=\"mail\"> \n";
for ($i=$int_firstl ine; $i<$int_number_ of_lines; $i++)
{
echo "<TR><TD>".$arr Log[$i]."</TR></TD>\n";
}
echo "</TABLE>\n";

?>

[Peter H. Coffin]

On Tue, 22 Apr 2008 07:06:24 -0400, Jerry Stuckle wrote:

Iván Sánchez Ortega wrote:

>Again, I don't think it's a good idea to load the entire file in memory.

Cheers,

It's fine for you to disagree. I don't see a problem when you have a
file which will be known not to grow to 100 MB.

.... Or some other arbitrary size that won't cause your system to go into
swap death. This is hardly a disagreement, btw.

--
"HTML's a cheap whore. Treating her with respect is possible, and even
preferable, because once upon a time she was a beautiful and virginal
format, but you shouldn't expect too much of her at this point." --M"K"H

[=?ISO-8859-15?Q?Iv=E1n_S=E1nchez_Ortega?=]

Jerry Stuckle wrote:

With your code it takes many more CPU cycles to accomplish the same
thing, during which time nothing else requiring CPU cycles can be
processed.

Pardon me?

Complexity of my algorithm (the same as GNU "tail") is O(n), where n is the
number of bytes that make up the desired lines at the end of the file.
Efficiency here depends on strrpos(), which has an complexity of O(n).

Complexity of your algorithm is O(m^2 * log(m)), where m is the total size
of the file. file() must check *every* character read to see if it's a line
break - that takes O(m). Then, you're doing count() - as PHP arrays are
hash tables (well, ordered maps), it is well known that transversing it
takes O(m*log(m)).

What is your basis to say that parsing the entire file is more CPU efficient
than parsing the last lines starting from the end? Because the way I see
it, O(n) << O(m^2*log(m)).
Cheers,
--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Un ordenador no es un televisor ni un microondas, es una herramienta
compleja.

[Jerry Stuckle]

Iván Sánchez Ortega wrote:

Jerry Stuckle wrote:

>With your code it takes many more CPU cycles to accomplish the same
thing, during which time nothing else requiring CPU cycles can be
processed.

Pardon me?

Complexity of my algorithm (the same as GNU "tail") is O(n), where n is the
number of bytes that make up the desired lines at the end of the file.
Efficiency here depends on strrpos(), which has an complexity of O(n).

Complexity of your algorithm is O(m^2 * log(m)), where m is the total size
of the file. file() must check *every* character read to see if it's a line
break - that takes O(m). Then, you're doing count() - as PHP arrays are
hash tables (well, ordered maps), it is well known that transversing it
takes O(m*log(m)).

What is your basis to say that parsing the entire file is more CPU efficient
than parsing the last lines starting from the end? Because the way I see
it, O(n) << O(m^2*log(m)).
Cheers,

tail is a compiled program. It is much more efficient than an
interpreted one.

And the only searching the program has to do is for the new line
character. Even in an interpreted language, that can be optimized be
quite a fast operation.

As opposed to multiple calls to seek and read the file, doing your own
searching... Much more code to go through and much more cpu intensive.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[=?ISO-8859-15?Q?Iv=E1n_S=E1nchez_Ortega?=]

Jerry Stuckle wrote:

As opposed to multiple calls to seek and read the file, doing your own
searching... Much more code to go through and much more cpu intensive.

Your argument doesn't hold here, Jerry. The longer "seek and read" algorithm
has a complexity of O(n), whereas the "file() - count() - for()" has
O(n^2*log(n)).

It just doesn't hold.

--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

MSN:i_********* *************** *@hotmail.com
Jabber:iv****** ***@jabber.org ; iv*********@kde talk.net

[Jerry Stuckle]

Iván Sánchez Ortega wrote:

Jerry Stuckle wrote:

>As opposed to multiple calls to seek and read the file, doing your own
searching... Much more code to go through and much more cpu intensive.

Your argument doesn't hold here, Jerry. The longer "seek and read" algorithm
has a complexity of O(n), whereas the "file() - count() - for()" has
O(n^2*log(n)).

It just doesn't hold.

You're assuming the path through the code is the same - or at least the
same length in cpu cycles. It isn't - not by a long shot.

Your argument is highly fallacious.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[=?ISO-8859-15?Q?Iv=E1n_S=E1nchez_Ortega?=]

Jerry Stuckle wrote:

Iván Sánchez Ortega wrote:

>The longer "seek and read" algorithm has a complexity of O(n), whereas
the "file() - count() - for()" has O(n^2*log(n)).

Your argument is highly fallacious.

Would you please elaborate?

--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Q: How does a hacker fix a function which
doesn't work for all of the elements in its domain?
A: He changes the domain.

[Jerry Stuckle]

Iván Sánchez Ortega wrote:

Jerry Stuckle wrote:

>Iván Sánchez Ortega wrote:

>>The longer "seek and read" algorithm has a complexity of O(n), whereas
the "file() - count() - for()" has O(n^2*log(n)).

Your argument is highly fallacious.

Would you please elaborate?

You assume either way takes the same number of cpu cycles. file() is a
single call to fetch the entire file. Searching for the new line
characters is also very fast, in cpu cycles (it can be highly optimized
in machine code). fopen(), then multiple fseek(), fread() and searching
yourself for the newline characters, followed by fclose() is much more
cpu intensive. This is true in a compiled language also, but in an
interpreted language the difference is even greater.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Baho Utot]

On Tue, 22 Apr 2008 21:40:01 -0400, Jerry Stuckle wrote:

[putolin]

Don't even try to compare performance in a compiled language vs. an
interpreted one. It's comparing apples and oranges.

Ever heard of perl?

--
Tayo'y Mga Pinoy

[Krustov]

<comp.lang.ph p>
<Baho Utot>
<Wed, 23 Apr 2008 16:45:11 -0400>
<pa************ *********@bilda net.com>

Ever heard of perl?

Isnt she a singer ? .
--
www.krustov.co.uk