Optimising things is strangely addicting, you start optimising, then you optimise, then you optimise, then you optimise, and before you know it a few hours have gone by, especially when you can benchmark each and every function with just a few lines and a command like with Go.
Got to have some self-control, hence you probably should go too far with optimisations, especially if it means putting the more important things on the sidelines. That said, let's go into optimising things.
There are many ways to optimise things, but for the web in particular, you will probably be firing off a few database queries.
Well. The fewer database queries you fire off, the faster things will run, it's really simple. Some say that the reason vB5 is so slow is because they have as many as a hundred queries on each page. But, you do have be careful here, because database queries can priceless in providing you with important functionality like being able to sort and filter lists and users won't be too happy, if they can't do that.
Cache all the things. Cache the results of computations rather than doing the same work over and over and over again. But be careful that the data doesn't go stale, sometimes this can be slightly tolerable, if it's outside of the bounds of what a human can perceive, but otherwise, it can be extremely problematic if seconds old or even minutes old content rear their ugly heads and the users run into odd edge cases.
Do less work. If you can cut the amount of work you do without any cost, then do it. The fastest work is the work you never do.
Copy less data. This is probably harder to do in interpreted languages where a lot of these decisions are done for you by the developers, whether it's for your benefit or against it, but less copying means faster executions, although be careful with going too far, particularly with primitives or insignificantly small bits of data, this can actually backfire.
About XML. XML isn't anywhere near as slow as the rumours suggest, unless you happy to be using PHP where it's 20 times slower than JSON, however the thing is generally a security hazard. If you happen to be using PHP, then well, you have yet another incentive not to use XML.
Use the simplest types you can when possible. No need to use a fancy object or hash table, if a tiny list or integer will suffice.
For JavaScript, avoid passing many different types and different objects to a single function, as it'll negatively affect your chances of it getting inlined or optimised, although again, don't let this stop you from writing algorithms which make sense.
For PHP, function calls are oddly expensive and unlike some languages, you have no hope of getting them inlined, however it is generally good practice to have short functions / methods which do one thing and do it well rather than doing eighty different things.
You can utilise code generation to generate bits of code tailored to your application rather than relying on slower possibly interpreted and generic implementations.
You probably want persistent applications rather than the classic PHP style of loading a script, loading all of the resources, initialising the data structures, serving the request, and then, throwing away all of that work and starting over on the next request.
Understanding the big o notation is also important or you wind up like MyBB's Cache System (although, I think that case was a workaround for PHP): https://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/ http://bigocheatsheet.com
There is no magic algorithm which can solve all problems and all situations. All algorithms within the systems you use whether it's the btrees in the database for the indices and what-not have certain trade-offs. Even something as "simple" as sorting something.
That's what I can think of for now, I'll see if I can think of more later, this is slightly tricky because optimisations for one platform are useless or are anti-optimisations on others.
Got to have some self-control, hence you probably should go too far with optimisations, especially if it means putting the more important things on the sidelines. That said, let's go into optimising things.
There are many ways to optimise things, but for the web in particular, you will probably be firing off a few database queries.
Well. The fewer database queries you fire off, the faster things will run, it's really simple. Some say that the reason vB5 is so slow is because they have as many as a hundred queries on each page. But, you do have be careful here, because database queries can priceless in providing you with important functionality like being able to sort and filter lists and users won't be too happy, if they can't do that.
Cache all the things. Cache the results of computations rather than doing the same work over and over and over again. But be careful that the data doesn't go stale, sometimes this can be slightly tolerable, if it's outside of the bounds of what a human can perceive, but otherwise, it can be extremely problematic if seconds old or even minutes old content rear their ugly heads and the users run into odd edge cases.
Do less work. If you can cut the amount of work you do without any cost, then do it. The fastest work is the work you never do.
Copy less data. This is probably harder to do in interpreted languages where a lot of these decisions are done for you by the developers, whether it's for your benefit or against it, but less copying means faster executions, although be careful with going too far, particularly with primitives or insignificantly small bits of data, this can actually backfire.
About XML. XML isn't anywhere near as slow as the rumours suggest, unless you happy to be using PHP where it's 20 times slower than JSON, however the thing is generally a security hazard. If you happen to be using PHP, then well, you have yet another incentive not to use XML.
Use the simplest types you can when possible. No need to use a fancy object or hash table, if a tiny list or integer will suffice.
For JavaScript, avoid passing many different types and different objects to a single function, as it'll negatively affect your chances of it getting inlined or optimised, although again, don't let this stop you from writing algorithms which make sense.
For PHP, function calls are oddly expensive and unlike some languages, you have no hope of getting them inlined, however it is generally good practice to have short functions / methods which do one thing and do it well rather than doing eighty different things.
You can utilise code generation to generate bits of code tailored to your application rather than relying on slower possibly interpreted and generic implementations.
You probably want persistent applications rather than the classic PHP style of loading a script, loading all of the resources, initialising the data structures, serving the request, and then, throwing away all of that work and starting over on the next request.
Understanding the big o notation is also important or you wind up like MyBB's Cache System (although, I think that case was a workaround for PHP): https://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/ http://bigocheatsheet.com
There is no magic algorithm which can solve all problems and all situations. All algorithms within the systems you use whether it's the btrees in the database for the indices and what-not have certain trade-offs. Even something as "simple" as sorting something.
That's what I can think of for now, I'll see if I can think of more later, this is slightly tricky because optimisations for one platform are useless or are anti-optimisations on others.
Last edited:
