a note on speed
Posted by
Sin Vraal (#18687) on Jan 14, 2023
calico remarked the site seems much faster...
it probably IS much faster. for a few reasons.
(technical post, dont read if you havent had coffee!)
several of the backend components have been rewritten.
1. old code for some of these components is 2-5k lines long, and used rather poor programming practices.
2. no libraries within the codebase exist, therefore there is much wasted code that is not reusable with other components on site,
3. almost the entire site is written using old old web1.0 style, and withing print "some stuff here" statements.
4. the database is ... "poorly designed", and the queries designed to pull data from it are "even more poorly designed"
what ends up happening,
1. is the web server has to compile this code every time. 5k lines of code means the script cannot be run until the 5k lines of code is compiled.
2. because each file has no shared components, these pages using very similar code (in many cases the same copy/pasted code!) have to be re compiled for each page. add a quarter second for each page on the site, and all of the sudden viewing 1000 pages results in a substantial time increase.
3. print statements can be fine when used properly, but if you print the entire page, php has to do what is called "string interpolation". this means each print statement needs to be parsed and looks for variables. this also results in difficult to modify html for the web design.
4. a badly designed database is a recipe for disaster. it can be mitigated a bit by using shared libraries. the poorly designed queries to pull the data however were murdering the speed.
what I have done so far:
I havent really even begun to construct updated pages. at this point, I am cleaning these 3 tasks.
1. streamline files. many of the sections I have re-written are 100-200 lines max. they load additional resources as required (a 5k line file doesnt typically need all the code.)
maybe by the end, 5-600 lines of code are compiled, and used.
2. many components are now shared. meaning if its cachable, its easier to gain advantage here. its also easier to update/ bugfix
3. php supports 'escaping' to regular html. when written in this way, php does not have to do "string interpolation". this results in MUCH faster code.
it also results in much CLEANER code. when the html is separate, it results in a file that can be edited by a regular web designer.
4. database queries are cleaned up whenever I see them. this is improving things a bit. but it takes a lot of time. (its also required in order to finally upgrade php version as well, since old php mysql functions are incompatible with later php versions)
anyway, this is a process. but after I've got the page mobile friendly, and a bit improved, we can get into making more features :)
it probably IS much faster. for a few reasons.
(technical post, dont read if you havent had coffee!)
several of the backend components have been rewritten.
1. old code for some of these components is 2-5k lines long, and used rather poor programming practices.
2. no libraries within the codebase exist, therefore there is much wasted code that is not reusable with other components on site,
3. almost the entire site is written using old old web1.0 style, and withing print "some stuff here" statements.
4. the database is ... "poorly designed", and the queries designed to pull data from it are "even more poorly designed"
what ends up happening,
1. is the web server has to compile this code every time. 5k lines of code means the script cannot be run until the 5k lines of code is compiled.
2. because each file has no shared components, these pages using very similar code (in many cases the same copy/pasted code!) have to be re compiled for each page. add a quarter second for each page on the site, and all of the sudden viewing 1000 pages results in a substantial time increase.
3. print statements can be fine when used properly, but if you print the entire page, php has to do what is called "string interpolation". this means each print statement needs to be parsed and looks for variables. this also results in difficult to modify html for the web design.
4. a badly designed database is a recipe for disaster. it can be mitigated a bit by using shared libraries. the poorly designed queries to pull the data however were murdering the speed.
what I have done so far:
I havent really even begun to construct updated pages. at this point, I am cleaning these 3 tasks.
1. streamline files. many of the sections I have re-written are 100-200 lines max. they load additional resources as required (a 5k line file doesnt typically need all the code.)
maybe by the end, 5-600 lines of code are compiled, and used.
2. many components are now shared. meaning if its cachable, its easier to gain advantage here. its also easier to update/ bugfix
3. php supports 'escaping' to regular html. when written in this way, php does not have to do "string interpolation". this results in MUCH faster code.
it also results in much CLEANER code. when the html is separate, it results in a file that can be edited by a regular web designer.
4. database queries are cleaned up whenever I see them. this is improving things a bit. but it takes a lot of time. (its also required in order to finally upgrade php version as well, since old php mysql functions are incompatible with later php versions)
anyway, this is a process. but after I've got the page mobile friendly, and a bit improved, we can get into making more features :)
a little slow. there is A LOT of code behind the dogs page.
progress:
1. setting purchase / lease fees finished up.
2. purchasing for bones or cash is cleaned and fixed.
3. leasing / stud fee in progress as soon as I find out where it is :)