| Author |
 Topic  |
|
Deleted
deleted
4116 Posts |
 Posted - 29 March 2002 : 12:29:56
|
This is what assoc lists do, it is named here "the dictionary object".
At the very beginning of the project (a year ago) the DB, FSO, Dictionary and Dynamic Include (may be some more) approaches were discussed for a couple of months.
Read this: http://forum.snitz.com/forum/topic.asp?TOPIC_ID=9447
As the "import to database" functionality needs FSO (btw I do it in Access), it is out of question (unless we write a user interface for db editing). There will be bug fixes around here, where the user needs to correct the code and has to add/delete/modify some strings in the database.
Think PinkPost v40b03 Patches< |
 |
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 29 March 2002 : 12:37:34
|
Nathan,
The more I think about that suggested way to create the array the more I get the impression that it may have the potential to actually be slower than the original solution and, also, eventually, to use as much memory as the original solution.
Why am I saying this. I'm just guessing, as I don't know the workings of the VB interpreter. But I'll let you in on my reasoning.
Using something like
arr(rs("STRING_ID")) = rs("LANG_STRING")
may lead to dynamic array resizing, which may envolve dynamic memory allocation, which is one of the slowest operations you can have in a program. Of course, you can create your SQL as to make it easy for you to know the highest ID involved and use that do Dim the array initially.
Won't such an array occupy more space than the actual one used? For example, if you specify arr(1300), won't this array have 1300 elements, of which only some will have meaningfull values? How does this improve in relation to the initial solution (remember that one of bozden's issue's was diminishing memory load on the server...)?
These issues and the slowness in recordset accessing ops make me doubt that these will bring any advantages over the initial solution...
-------------------------------------------------
Installation Guide | Do's and Dont's | MODs
Edited by - ruirib on 29 March 2002 12:40:40< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 March 2002 : 12:43:06
|
Btw, I continue to consider the JS approach as an option (will see if it works), which will "share" the load with the client  .
Think PinkPost v40b03 Patches< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 March 2002 : 12:44:54
|
quote:
These issues and the slowness in recordset accessing ops make me doubt that these will bring any advantages over the initial solution...
How much  .
Think PinkPost v40b03 Patches< |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 29 March 2002 : 12:44:55
|
quote:
This is what assoc lists do, it is named here "the dictionary object".
Lost you on this one...
quote:
At the very beginning of the project (a year ago) the DB, FSO, Dictionary and Dynamic Include (may be some more) approaches were discussed for a couple of months.
Read this: http://forum.snitz.com/forum/topic.asp?TOPIC_ID=9447
Out of reach for mere "mortals" like me. I get a message saying that I don't have access to that forum.
quote:
As the "import to database" functionality needs FSO (btw I do it in Access), it is out of question (unless we write a user interface for db editing). There will be bug fixes around here, where the user needs to correct the code and has to add/delete/modify some strings in the database.
If you see my other posts you'll see that I'm very doubtful about the merits of a DB based solution, at least in the sense that it seems that it wouldn't do much to overcome the server load problems you referred to initially. So no point in pursuing this option, at least now...
Edited by - ruirib on 29 March 2002 12:45:54< |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
|
|
Deleted
deleted
4116 Posts |
Posted - 29 March 2002 : 12:53:42
|
quote:
quote:
This is what assoc lists do, it is named here "the dictionary object".
Lost you on this one...
You were just quick :( I meant "accessing an array with the variable name" idea. A couple posts above.
quote:
quote:
At the very beginning of the project (a year ago) the DB, FSO, Dictionary and Dynamic Include (may be some more) approaches were discussed for a couple of months.
Read this: http://forum.snitz.com/forum/topic.asp?TOPIC_ID=9447
Out of reach for mere "mortals" like me. I get a message saying that I don't have access to that forum.
Interesting mistake from me! Read this: http://forum.snitz.com/forum/topic.asp?TOPIC_ID=9447 (first post is enough I think... It's very long)
(meal time)
Think PinkPost v40b03 Patches< |
|
|
|
Deleted
deleted
4116 Posts |
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 29 March 2002 : 13:00:08
|
No I don't. I'm just guessing, given the nature of the operations involved. I could almost bet on it, but I know better than that. But testing will ne needed to prove me right or wrong.
<edit>I will try to simulate something...</edit>
I still cannot reach that link you gave. I'm simply not an allowed member of that forum, I guess.
-------------------------------------------------
Installation Guide | Do's and Dont's | MODs
Edited by - ruirib on 29 March 2002 13:01:32< |
|
|
|
Nathan
Help Moderator
USA
7664 Posts |
Posted - 29 March 2002 : 14:45:50
|
quote:
Btw, I continue to consider the JS approach as an option (will see if it works), which will "share" the load with the client .
Don't do anything client side. Remember, this may have to be compatable with browsers and operating systesm that don't exist yet.
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's< |
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 29 March 2002 : 15:01:41
|
Sorry, would have joined in but been having connection problems.
The entire record set can be fetched into an array with a single call to getRows(), this is very quick and has been tested on access,MySQL and SQL. so would not be a great server hit.
admittedly these now need to be indexed, but they could easily be put in a dictionary object.
Surely using a db would mean that multilanguage was a much more viable proposition, since a user could choose his language and the query would select the relevant string, something you could not do using include files.
Why would updates require the fso ?
update files could be written to insert strings using either the mod_setup prog (if they can use the fso) or I have an online tool which will read a dbs file and create you the correct asp script to update the db, so we could just provide those.
< |
|
|
|
Nathan
Help Moderator
USA
7664 Posts |
Posted - 29 March 2002 : 15:07:49
|
The FSO was part of the include file idea. To use FSO to make your languages web-configurable instead of editing config.asp every time. Unless I am missing somthing. With a datbase there should be no need for fso, or direct editing of config.asp
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 March 2002 : 16:43:11
|
quote:
I still cannot reach that link you gave. I'm simply not an allowed member of that forum, I guess.
 I again gave the same wrong link. This is the correct one: http://forum.snitz.com/forum/topic.asp?TOPIC_ID=8433
I'm not against re-thinking the whole process although some work will get lost and the topic was about how to make the current approach better. The thing is, I did it this way because we decided to make it this way (back to June 2001). The current approach was decided by Pierre (Gor), Mike and me on June 2001, it was a jointly developed idea and I continued to develop that.
As the topic goes a bit out of its route, I'll prepare some more start-up "documents" (remember, this was numbered 1) on issues like distribution, maintaining etc, so that we can see the whole range.
Please make sure you read the above posted link.
Think PinkPost v40b03 Patches< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 29 March 2002 : 16:45:39
|
quote:
quote:
Btw, I continue to consider the JS approach as an option (will see if it works), which will "share" the load with the client .
Don't do anything client side. Remember, this may have to be compatable with browsers and operating systesm that don't exist yet.
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's
I don't think this will be a problem. If the client has a compatible JS support, then JS will be executed, or ASP will provide it. Before going further on this, I need some experimentation.
Think PinkPost v40b03 Patches< |
|
|
|
ruirib
Snitz Forums Admin
Portugal
26364 Posts |
Posted - 29 March 2002 : 17:12:52
|
Ok. I did some testing, just to have a more concrete idea of what I was talking about.
I did try 3 scripts:
Method 1. I changed lang2070.asp to include just the strings assignments and to have a timer to count the time to complete the script. As my first test showed very small timings, I created a for loop, so that the assignments are done 100 times.
Method 2. Using a table from one of my Access DBs I created a setup as described by Nathan. Read a recordset with two fields, an ID and a string, ordered from higher ID downto lower ID and created an array indexed by String_ID, using the exact process sugested by Nathan.
Method 3. Similar to two, but I got the recordset to an auxiliary array using GetRows and then created the array indexed by String_ID using this auxiliary array.
Here are results (using my Celeron 800MHz, 392MB RAM, Win XP Pro)
Test1. lang.asp with 1971 strings or DB with 1971 records
Method 1 (assigining 1971 string vars x 100) : 0,65 - 0,67 secs
Method 2 (read recordset with 1971 records x 1): 0,21 - 0,23 secs
Method 3 (read recordset with 1971 records x 1): 0,13 - 0,14 secs
Test2. lang.asp with 500 strings or DB with 500 records
Method 1 (assigining 500 string vars x 100) : 0,14 - 0,16 secs
Method 2 (read recordset with 500 records x 1): 0,11 - 0,12 secs
Method 3 (read recordset with 500 records x 1): 0,085 - 0,10 secs
Test3. lang.asp with 250 strings or DB with 250 records
Method 1 (assigining 250 string vars x 100) : 0,039 - 0,046 secs
Method 2 (read recordset with 250 records x 1): 0,086 - 0,10 secs
Method 3 (read recordset with 250 records x 1): 0,075 - 0,085 secs
Test4. lang.asp with 100 strings or DB with 100 records
Method 1 (assigining 100 string vars x 100) : 0,0078 - 0,0,046 secs
Method 2 (read recordset with 100 records x 1): 0,075 - 0,0095 secs
Method 3 (read recordset with 100 records x 1): 0,075 - 0,085 secs
As you can see there is a significative advantage in speed with the use of strings defined in an include file (don't forget that in this case the assignments are repeated 100 times). For a lower number of records the difference is even more striking, and it seems that for a sufficient low number of records the overhead of DB Access is more relevant than the number of records read (the times for 100 records or 250 records are similar).
This seems to indicate that if you choose a DB based approach vs. a include file approach that choice cannot be based on a performance criteria. Probably if you consider the memory used in each approach the results can be similar.
I can provide you the code and the DB, if you guys want to test by yourselves. Obviously this should be seen as merely indicative.
This is not very surprising to me. I guess if I used an ODBC driver (I used the OLEDB provider) it would be even more favourable to the string based approach.
Didn't test this with SQL Server. Maybe it could diminish the difference. Maybe I'll try it sometime.
-------------------------------------------------
Installation Guide | Do's and Dont's | MODs
Edited by - ruirib on 29 March 2002 17:19:18< |
|
|
|
Topic |
|
Forum Locked
