output large arrays to html

[Brian Huntington]

Hello,

I'm looking for ways to 'echo' a single large associative array
repeatedly w/ as little overhead as possible.

I'm developing a simple subscription form, two steps, one page. In
step 1 the subscriber selects their country from a drop down menu
whose name and value pairs are based on ISO standards. In step 2 user
has the option to return to 1 and edit.

I mined the ascii data from the ISO Web page src, edited it, and
dumped it to MySQL, intending to dynamically generate my menu. But now
I'm concerned that every time a subscriber wishes to edit input, they
will experience a lag in the middle of the page while some 200+ select
options are echo'ed to the screen.

I've attempted to solve that concern using the following technique in
a global scope:

if (!isset($huge_assoc_array))
$huge_assoc_array = mine_from_db();

Does this accomplish the intended result, reducing print-to-screen
time on requests beyond the first? If subscriber clicks input button
'edit,' returning to step one, will mine_from_db() execute again?

Not sure of the answer, I've considered two alternative techniqes:
a) $_SESSION['huge_assoc_array'] = mine_from_db(); and
b) using Curl or similar to mine, on each request, from iso.org.

If you've dealt with this I would love to hear your success and
failure stories.

Thanks for any advice,
Brian Huntington

[Jochen Daum]

Hi Brian!
On 20 Nov 2003 19:42:13 -0800, bh*********@agu.org (Brian Huntington)
wrote:

Hello,
(...)
I mined the ascii data from the ISO Web page src, edited it, and
dumped it to MySQL, intending to dynamically generate my menu. But now
I'm concerned that every time a subscriber wishes to edit input, they
will experience a lag in the middle of the page while some 200+ select
options are echo'ed to the screen.
Have you measured how long it takes? Have a look at microtime(). I
think it does take barely any time in relation to transferring it to
the client browser.

I've attempted to solve that concern using the following technique in
a global scope:

if (!isset($huge_assoc_array))
$huge_assoc_array = mine_from_db();

Does this accomplish the intended result, reducing print-to-screen
time on requests beyond the first? If subscriber clicks input button
'edit,' returning to step one, will mine_from_db() execute again?
On every reload.

Not sure of the answer, I've considered two alternative techniqes:
a) $_SESSION['huge_assoc_array'] = mine_from_db();
less overhead with the db, but takes disk space from all users on the
server. b) using Curl or similar to mine, on each request, from iso.org.
Thats definitely slower than fetching it (cached!) from a db on teh
server.

If you've dealt with this I would love to hear your success and
failure stories.

I have a page with about 15 selects with around 2000 options and it
takes low spec machines (32MB) about 2 seconds to render the page. All
come from the db and take around 1 second to fetch. The server side
time is relatively small in relation to the time for transferring it
to the browser and rendering it.

You only have a problem, if a large amount of your users has the
select boxes on their screen, as it will then eat server resources.
But I suppose they will click links most of the time rather than
filling forms (which takes human interaction == time)

HTH, Jochen
--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/

[André Næss]

Brian Huntington:

Hello,

I'm looking for ways to 'echo' a single large associative array
repeatedly w/ as little overhead as possible.

I'm developing a simple subscription form, two steps, one page. In
step 1 the subscriber selects their country from a drop down menu
whose name and value pairs are based on ISO standards. In step 2 user
has the option to return to 1 and edit.

I mined the ascii data from the ISO Web page src, edited it, and
dumped it to MySQL, intending to dynamically generate my menu. But now
I'm concerned that every time a subscriber wishes to edit input, they
will experience a lag in the middle of the page while some 200+ select
options are echo'ed to the screen.

I keep saying this a lot ... Oh well: "Premature optimization is the root of
all evil." - Donald Knuth.

But why you are storing the countries in a MySQL database is beyond me, just
put them directly in an array.

André Næss

[Eric Kincl]

Jochen Daum wrote:

Hi Brian!
On 20 Nov 2003 19:42:13 -0800, bh*********@agu.org (Brian Huntington)
wrote:

Hello,

(...)

I mined the ascii data from the ISO Web page src, edited it, and
dumped it to MySQL, intending to dynamically generate my menu. But now
I'm concerned that every time a subscriber wishes to edit input, they
will experience a lag in the middle of the page while some 200+ select
options are echo'ed to the screen.

Have you measured how long it takes? Have a look at microtime(). I
think it does take barely any time in relation to transferring it to
the client browser.

I've attempted to solve that concern using the following technique in
a global scope:

if (!isset($huge_assoc_array))
$huge_assoc_array = mine_from_db();

Does this accomplish the intended result, reducing print-to-screen
time on requests beyond the first? If subscriber clicks input button
'edit,' returning to step one, will mine_from_db() execute again?

On every reload.

Not sure of the answer, I've considered two alternative techniqes:
a) $_SESSION['huge_assoc_array'] = mine_from_db();

less overhead with the db, but takes disk space from all users on the
server.

b) using Curl or similar to mine, on each request, from iso.org.

Thats definitely slower than fetching it (cached!) from a db on teh
server.

If you've dealt with this I would love to hear your success and
failure stories.

I have a page with about 15 selects with around 2000 options and it
takes low spec machines (32MB) about 2 seconds to render the page. All
come from the db and take around 1 second to fetch. The server side
time is relatively small in relation to the time for transferring it
to the browser and rendering it.

You only have a problem, if a large amount of your users has the
select boxes on their screen, as it will then eat server resources.
But I suppose they will click links most of the time rather than
filling forms (which takes human interaction == time)

HTH, Jochen

Ya, I just made a script that prints 4000+ lines from SQL to the browser,
and it takes no time at all. (I'm connecting to localhost, so download
times are instantaneous. I notice no lag at all)

[Brian Huntington]

Jochen Daum <jo*********@cans.co.nz> wrote in message news:<mb********************************@4ax.com>. ..

Hi Brian!
On 20 Nov 2003 19:42:13 -0800, bh*********@agu.org (Brian Huntington)
wrote:

Hello,

(...) etc..
Have you measured how long it takes? Have a look at microtime(). I
think it does take barely any time in relation to transferring it to
the client browser.

Thanks for the suggestions Jochen. On your advice I timed the block of
code that mines and prints country option pairs. Every load produced
results less than two tenths of a second. Several reloads were in
hundreths of a second. I'm very pleased with the results, as they are
much better than I expected. Thank you for pointing me in the right
direction so that I could debunk my suspicions regarding over-long
print-to-screen times.

Brian H.