pfSense

Oh sorry. Guess I was a bit too light on info there. But it was bad enough on both Chrome and IE that I just neglected to include further details.

Chrome:
What I posted in the original opening ticket is regarding Chrome. ~75 seconds for 2.3 and ~10 seconds for 2.2.6. A factor of 7 is quite a difference. In your 11 vs. 25 seconds that is more than 2x factor. Don't think I would consider that to be small.

IE:
Like you IE is far worse. On 2.3 I waited 5 to 6 minutes and IE finally crashed. It just closed without warning. As though I had closed it. Though on 2.2.6 IE is fine at ~10 seconds just like 2.3.

Windows 8.1 Pro

Though on 2.2.6 IE is fine at ~10 seconds just like 2.3.
Meant to say ... just like Chrome.

bogons isn't long enough, bogonsv6 is though. Just picking bogonsv6 from the drop down on diag_tables.php will show the issue.

As Chris mentioned. The bogons list isn't large enough. Need to select bogonsv6 to see the issue.

Using Firefox bogons6 just locks up the browser for ever. Even removing all the table code and disabling javascript like this:

foreach ($entries as $entry):
print($entry . "<br />");
endforeach;

kills Firefox and takes for ever in Chrome. I guess 680,000 lines of text will do that.

Perhaps we need to do some server side paging?

Same table in ver. 2.2.6 isn't a problem in any of those browsers.

understood, but I still have to perform triage, or we won't ever get to a 2.3-RELEASE

Jim Thompson wrote:

lowering priority. This isn't required functionality (it's part of the diag menu, and there is a lot of poorly considered code in that area), and while it's slow, it's not broken, assuming your browser doesn't run out of ram.

That's broken.
Ability to view tables is required functionality.

Steve Beaver wrote:

Using Firefox bogons6 just locks up the browser for ever. Even removing all the table code and disabling javascript like this:

foreach ($entries as $entry):
print($entry . "<br />");
endforeach;

kills Firefox and takes for ever in Chrome. I guess 680,000 lines of text will do that.

Perhaps we need to do some server side paging?

Where you coming up with 680,000? The bogonsv6 is only 66,386 records.

Remove that line break and loading will be nearly instant. Second or two at most. Even with the javascript stuff still there.

This loads in a few seconds. Removing the tr and td tags and leaving only the pre tag it loads near instantly.

echo "Rows: " . count($entries) . "<br />";
echo "<tr><td><pre>";
foreach ($entries as $entry):
    print $entry . "\n";
endforeach;
echo "</pre></td></tr>";

OK so I was a factor of ten out :)

The slowness appears to be coming from the table sorting library. As a workaround I added a flag to prevent that from being loaded on this page. I will look for a better solution when times permits.

Steve Beaver wrote:

OK so I was a factor of ten out :)

The slowness appears to be coming from the table sorting library. As a workaround I added a flag to prevent that from being loaded on this page. I will look for a better solution when times permits.

That doesn't seem to improve it here.
Removing the stylesheets links from head.inc lines 87,88,89 cuts the load time down to 15 seconds in Chrome.

I'm thinking the root of this is going to be something to do with the nested css.

still just locks up my Firefox and IE when attempting to load that page.

Steve Beaver wrote:

Perhaps we need to do some server side paging?

Problem with that is losing the ability to search the table for an address. Not fond of that.

Chris Buechler wrote:

still just locks up my Firefox and IE when attempting to load that page.

I'm displaying tables larger than 3000 records in a pre tag. Similar to what I showed above. Loads in just few seconds for both IE and Chrome. I can submit it if you like. But it really is just a Band-Aid. But at least it's functional and convenient to use.

Not loading the sorting stuff makes the difference between locking up the browser and slow but usable for me so I will retain that. I would welcome a PR that improves the speed.

In practice, is bogon6 the only case where we see tables of 60,000 entries? Other table types render a button so we can't just pre tag the whole table.

There are a lots of lists available from many sources. Many of them are quite large. I use a CIPB (COUNTRY IP BLOCKS) U.S. networks list that is about 48K records.

Submitted my pre tag band-aid. PR # 2669.

I'd prefer not to have the whole thing pre tagged. It's nice to have the tables formatted where performance is practical. Plus it doesn't blind you with a bright background in the dark theme. Though I'm sure that could be resolved with some css.

Agreed. Thanks again for the patch. I'll as Jared to look over the CSS to see if he can find an issue there.

Doing some more testing this morning I find that the browser lockup I was seeing is peculiar to one particular version of Firefox on OS-x (45.0b6). When using the developer version, Chrome or Safari NOYB's work-around is super fast, displaying the 66,000 entry table in less than 2 seconds. I will assume its a glitch in that version (which is a Beta version after all)