I read an interesting quote on a Python forum that it's "easier to ask for forgiveness than it is to ask for permission". I'm not too familiar with the language so I can't say whether this is garbage. From working with .NET, it is my understanding that a try catch is an expensive operation and should be there for exception cases only. Kind of like a safety net.
Is there any merit to this type of behaviour with php? As in, is it quicker to read from a file inside a try catch vs checking to see if the file can be found / read before performing the read operation. I can see how it makes the code easier to maintain, but what are the perfoance implications. Is it more of a waste to check when 99.9% of the time the check is pointless.
To the best of my knowledge, this is not a standard practice in PHP. This is, in large part, because most PHP builtins threw PHP errors -- not exceptions! -- prior to PHP 7.0. PHP errors could not be caught by PHP try/catch blocks, making it mandatory to use explicit checks for functions that could fail.
If your code needs to be compatible with PHP 5.6 or earlier, you can't use this convention. It may be worth experimenting with if you can mandate PHP 7.0 or later for your code, but I don't know what implications this may have for performance.
Try and catch by itself is truly quite expensive. Even when it is not used (i.e. no exception is generated), there is still some overhead that is "embedded" into the generated assembly. As for simple check whether the file exists and can be accessed, same thing happens: both of the things are system calls that are generally even more expensive. You should, however, also consider that the read operation on a file is a system call as well.
Now the question is narrowed down to what is more expensive: 2 system calls or 1 syscall with the exception handling. My assumption here (which I am somewhat confident about) is that the latter will be more expensive in case where the exception is actually being thrown, but faster in other cases. Since you've indicated that there will, in most cases, be no problems with accessing the files, it may be the case that you "should" use the exceptions. It is easier to deal with errors and does make the code a little bit more pretty (although it is arguable).
A little bit more on the code side of things: it totally depends on what your framework looks like now and what you want it to look like. You can, in fact, create a class that will deal with all this stuff in any of the two ways and they both will look clean (if done properly) and easily maintainable. If, however, you don't feel like keeping it in a separate class (or a separate file\function\universe), I would go for the exception handling.
Finally, as said before, the exception handling will generally be faster in you case, but ask yourself a question: How much of a problem is it? Do you perform the operation once per page access or do you do it multiple times? Will the page be accessed often or just once a day? How much of an impact will this create compared to all the other pages\algorithms that you have. There is a good concept know as 90/10 rule: 90% of the code is executed 10% of the time and vice versa. If this particular code is in these 90%, you shouldn't even worry about the performance as your concern should be the other 10% of the code. (You can read more about this here)
And one more thing: as noted by duskwuff, whatever is written here holds for PHP version >= 7.0
Related
First of all - there seem to be many questions about the fundamentals of tick functionality, so I want to add the top user comment at php.net/declare to the pile for anyone looking for further information. I found it while digging around as I tried to figure out the following.
So, I'm working on writing a simple debug helper. I want to add function tracing and benchmarking - basically what tick functionality is perfect for.
Thing is, I want to enable and disable benchmarking depending on arbitrary conditions that occur during script processing. I'm not really looking for fixed debugging à la scoped declare() { ... }.
What I'm looking to do is to put declare(); at the top of my script, and then register and unregister my debugging/benchmarking (tick) function as appropriate. Un/registration won't happen (too) often, so is efficient and reasonable.
But then I got curious: when I don't have a tick function registered... does the fact that I've run declare(ticks=1); have any effect on execution efficiency? Does it cause any extra processing to become permanently enabled anyway?
Analysis of PHP(7)'s source code shows that the answer is technically yes, but I'm not yet sure how.
The answer seems to be in zend_compile.c:8200: it appears this function defers compilation processing to the appropriate routines, then if ticks are enabled it additionally emits a ZEND_TICKS opcode into the opline via zend_emit_tick() in :2167. The opcode reference page for TICKS seems consistent with this conclusion; it shows an example disassembled opcode listing which has TICKS opcodes scattered throughout it, and I was wondering how they got in there until I discovered the above.
The ZEND_TICKS handler (in zend_vm_def.h:6859) seems to call zend_ticks_function(). This is mapped to ticks_function() in zend.c:754, which is in turn mapped to php_run_ticks() in main.2013. This is finally defined in php_ticks.c, where it's all of:
void php_run_ticks(int count)
{
zend_llist_apply_with_argument(
&PG(tick_functions),
(llist_apply_with_arg_func_t) php_tick_iterator,
&count
);
}
Huh. Not bad.
But here's the thing. If I declare(ticks=1);, the above dispatch is being run for literally every statement executed. That's... ouch. For long-running scripts containing high-iteration-count, tight processing loops, I'm wondering how badly that'll add up.
Problem is, I'm not even sure how to benchmark this. The only way I could envisage to do so would be to synthesize some PHP bytecode and then figure out a way to inject that directly into the PHP bytecode interpreter.
And that leads to my question: how much of a performance impact does this additional dispatch have, in practice? How can I quantify it?
Obviously the above investigation was performed on the canonical PHP.net interpreter. I haven't looked into how HHVM does this at all (yet), but I wouldn't at all mind learning how it handles it.
I have a PHP code stored in the database, I need to execute it when retrieved.
But my code is a mix of HTML and PHP, mainly used in echo "";
A sample that looks like my code:
echo "Some Text " . $var['something'] . " more text " . $anotherVar['something2'];
How can I execute a code like the either if I add the data to the DB with echo""; or without it.
Any ideas?
UPDATE:
I forgot to mention, I'm using this on a website that will be used on intranet and security will be enforced on the server to ensure data safety.
I have a PHP code stored in the database
STOP now.
Move the code out of the database.
And never mix your code with data again.
It's not only a bad idea but also invitation to several type of hacking attempts.
You can do with eval(). but never use it . The eval() is very dangerous because it allows execution of arbitrary PHP code. Its use thus is discouraged. If you have carefully verified that there is no other option than to use this construct, pay special attention not to pass any user provided data into it without properly validating it beforehand.
See eval. It lets you pass a string containing PHP and run it as if you'd written it directly into your file.
It's not a common practice to store executable PHP in a database; is the code you store really that different that it makes more sense to maintain many copies of it rather than adapting it to do the same thing to static data in the database? The use of eval is often considered bad practice as it can lead to problems with maintenance, if there's a way of avoiding it, it's normally worth it.
You can execute code with eval():
$code_str = "echo 'Im executed'";
eval($code_str );
BUT PAY ATTENTION that this is not safe: if someone will get access on your database he will be able to execute any code on your server
use the eval() function.
heres some info
http://www.php.net/manual/en/function.eval.php
something along the lines of:
eval($yourcode);
If that is the last resort, you want it to be secure as it will evaluate anything and hackers love that. Look into Suhosin or other paths to secure this in production.
As everyone'd indicated using eval() is a bad approach for your need. But you can have almost the same result by using whitelist approach.
Make a php file , db_driven_functions.php for instance. get your data from db. and map them in an array as below
//$sql_fn_parameters[0] = function name
//$sql_fn_parameters[1,2,3.....] = function parameters
Then define functions those include your php code blocks.for instance
my_echo($sql_fn_parameters){
echo $sql_fn_parameters[1];//numbered or assoc..
}
then pull the data which contains function name
after controlling if that function is defined
function_exists("$sql_fn_parameters[0]")
call function
call_user_func_array() or call_user_func()
( any you may also filter parameters array $sql_sourced_parameters_array does not contain any risky syntaxes for more security.)
And have your code controlled from db without a risk.
seems a little bit long way but after implementing it's really a joy to use an admin panel driven php flow.
BUT building a structure like this with OOP is better in long term. (Autoloading of classes etc. )
Eval is not safe obviously.
The best route IMO
Save your data in a table
Run a stored procedure when you are ready to grab and process that data
You should not abuse the database this way. And in general, dynamic code execution is a bad idea. You could employ a more elegant solution to this problem using template engines like Smarty or XSLT.
There are a few way to achieve this:
1) By using evil
eval($data);
That's not a typo, eval is usually considered evil and for good reasons. If you think you have fully validated user data to safely use eval, you are likely wrong, and have given a hacker full access to your system. Even if you only use eval for your own data, hacking the database is now enough to gain full access to everything else. It's also a nightmare to debug code used in eval.
2) Save the data to a file, then include it
file_put_contents($path, $data); include $path;
There are still the same security concerns as eval but at least this time the code is easier to debug. You can even test the code before executing it, eg:
if (strpos(exec('php -l '.$path), 'No syntax errors detected') === false))
{
include $path;
}
The downside to this method, is the extra overhead involved in saving the code.
3) Execute the code straight from the database.
You'd need to use database software that allows this. As far as I am aware, this is only includes database software that stores the content as text files. Having database software with "php eval" built in would not be a good thing. You could try txt-db-api. Alternatively, you could write your own. It would like become very difficult to maintain if you do though but is something to consider if you know exactly how you want your data to be structured and are unlikely to change your mind later.
This could save a lot of overhead and have many speed benefits. It likely won't though. Many types of queries run way faster using a traditional database because they are specifically designed for that purpose. If there's a possibility of trying to write to a file more than once at the same time, then you have to create a locking method to handle that.
4) Store php code as text files outside of the database
If your database contains a lot of data that isn't php code, why even store the php code in the database? This could save a lot of overhead, and if you're database is hacked, then it may no longer be enough to gain full access to your system.
Some of the security considerations
Probably more than 99% of the time, you shouldn't even be attempting to do what you are doing. Maybe you have found an exception though, but just being an intranet, isn't enough, and certainly doesn't mean it's safe to ignore security practices. Unless everyone on the intranet needs full admin access, they shouldn't be able to get it. It's best for everyone to have the minimum privileges necessary. If one machine does get hacked, you don't want the hacker to have easy access to everything on the entire intranet. It's likely the hacker will hide what they are doing and will introduce exploits to later bypass your server security.
I certainly need to do this for the CMS I am developing. I'm designing it mainly to produce dynamic content, not static content. The data itself is mostly code. I started off with simple text files, however it slowly evolved into a complicated text file database. It's very fast and efficient, as the only queries I need are very simply and use indexing. I am now focusing on hiding the complexity from myself and making it easy to maintain with greater automation. Directly writing php code or performing admin tasks requires a separate environment with Superuser access for only myself. This is only out of necessity though, as I manage my server from within, and I have produced my own debugging tools and made an environment for code structured a specific way that hides complexity. Using a traditional code editor, then uploading via ssh would now be too complicated to be efficient. Clients will only be able to write php code indirectly though and I have to go to extreme lengths to make that possible, just to avoid the obvious security risks. There are not so obvious ones too. I've had to create an entire framework called Jhp and every piece of code, is then parsed into php. Every function has to pass a whitelist, is renamed or throws an error, and every variable is renamed, and more. Without writing my own parser and with just a simple blacklist, it would never be even a tiny bit secure. Nothing whatsoever client-side can be trusted, unless I can confirm on every request that it has come entirely from myself, and even then my code error checks before saving so I don't accidentally break my system, and just in case I still do, I have another identical environment to fix it with, and detailed error information in the console that even works for fatal errors, whilst always been hidden from the public.
Conclusion
Unless you go to the same lengths I have (at minimum), then you will probably just get hacked. If you are sure that it is worth going to those lengths, then maybe you have found an exception. If your aim is to produce code with code, then the data is always going to be code and it cannot be separated. Just remember, there are a lot more security considerations other than what I have put in this answer and unless the entire purpose of what you are doing makes this a necessity, then why bother at all mix data with code?
Think of PHP templating.
I was recently contemplating whether it makes sense to read a template file once, storing it in memory, and then parsing it (replace placeholders with values, e.g.) rather than require-ing that file as many times as you need it. A usage scenario would be a list with list items templated as separate files. The first thoughts I had were inclined towards the former solution, because I reckon replacing values would be an easier operation than requiring the file from the file system. Later, however, I realized that pretty much all hard disk drives (or other storage, for that matter) have their own caching, and requiring the same file over and over, will not result in it being re-read each time, but rather re-served from the cache.
Any thoughts are appreciated.
I assume by "disk cache" you're actually referring to the page cache? Wikipedia: Page Cache
If so I wouldn't really be inclined to trust something like this with the performance of my application. Don't forget the page cache only uses UNUSED memory and will happily spit it back out when needed.
I would be inclined to use something like APC as an object cache, this has the great side effect of not having to actually rewrite any of your code as it's all done behind the scenes. Another possibility would be to just assign your template to a variable and constantly reuse that. Or, if you wanted to you could even use Memcache, this kind of stuff is more useful for caching database returns though, or large datasets.
Sorry for the slightly incoherent ramblings...
I was recently contemplating
That's quite wrong of you.
Groundless contemplating out of nowhere seldom does any good but most likely will put you in a trouble. Just out of nowhere.
Instead of contemplating, one have to do profiling.
Of course no to measure any changes, like H Hatfeld said, but to determine, if they need any changes at all. Most of time it turns out that you were barking wrong tree.
Profiling is the right thing to make you bark the right one.
whether it makes sense to read a template file onc, estoring it in memory, and then parsing it
For the highload(or bloated) projects it makes.
So, PHP already have such a feature, called bytecode cache. There is a plenty of the thing on the market, at our company we are using eAccelerator.
But most of time default every-request parsing is enough.
You are absolutely right about filesystem cache and parsing being blazingly fast, much faster than usual application logic, which has to be optimized at the first place.
Every time you include a file, PHP has to parse it. This penalty can be offset using an opcode cache like APC. If your templates don't contain any PHP (which it sounds like they don't), I would recommend loading the template into memory once and then re-using it as needed.
Another thing to keep in mind when looking to optimize your code is make sure you can measure the change. Use something like Xdebug to profile your code and measure what effect your changes are having.
Edit
Since the files do currently contain PHP, take a look at this question/answer. I would recommend putting a function in the file so that it only needs to be loaded once, but can be called multiple times with different parameters.
Do you position all of your include_once and require_once at the start of the file, so it's clear what it's dependencies are, or do you put them at the most local scope where they are used, for efficiency?
Let's say I have an error handling file which has a function to display an error message - would you ...
require_once('error_handling.php');
... lots of code ...
if ($should_be_true === False)
{
ReportErrror(); // declared in error_handling.php
}
or do you
... lots of code ...
if ($should_be_true === False)
{
require_once('error_handling.php');
ReportErrror(); // declared in error_handling.php
}
hmm, looks like they deleted the best-practise tag, along with subjective in the great tag purge of '10
This is probably a matter of taste for the most part.
In C/C++ style, I always put them on top, so - as you mentioned - the dependencies are immediately clear. Also, it gives you the option to rearrange the order of inclusion (which should normally never matter).
Now, since this is a runtime affair (unlike C/C++), it would make sense to postpone including huge files that are rarely ever needed.
It's a matter of balance - cleaner code (IMHO) vs performance. I would tend towards cleaner code, unless you have a PHP file that is a) called a lot, b) uses a huge PHP file that is c) almost never needed.
I'd most definitely go with the second example, because to load in stuff that potentially wouldn't be used is just evil.
Meh. Totally dependent on the situation.
If it's a small include and you're going to use it in 95% of situations, top is fine. Top really is fine for almost all cases.
But if it's an absolutely huge library to, say, parse something that will only come up in 5% of requests, require when needed. It might be worth making a comment at the top to make the dependency known, however—happy medium?
Anyway. It's a judgment call every time. Best not worry too much about the performance issue for the uncertain cases until milliseconds of performance actually become an issue for you. (And wouldn't that sort of popularity be an excellent issue to have?)
The "goto" statement comes straight out of ASM or any other assembler language.
Here's a link: http://be2.php.net/manual/en/control-structures.goto.php
I'm wondering: what can this do to make my code more well-organized? How can I implement this in larger projects, without screwing it up.
Since the goto will allow you to jump back and forth, accidental assignments and infinite loops are waiting to happen if you use this the wrong way.
Can someone give me an example of a good use of this?
EDIT: allright, I've seen some of the replies and apparently a wide consensus exists about the use of the "goto" statement and it being bad.
So I'm still wondering: why would PHP bother to add it to the language. If they didn't see something in it, they wouldn't do it... so why?
Also: A discussion here on StackOverflow about "goto" in general
EDIT2: Seeing as this question induced a lot of bad things to be sad about the goto statement, I went and asked my father. He's 52 years old and is an Industrial Engineer. He told me a couple of times he did a good amount of programming in his days and mostly in FORTRAN and COBOL. Nowadays he does IT services, server&networkmanagment and such.
Anyways, he said some stuff about "back in my day..."
After discussing that a bit, he came back to the goto statement, saying that even back in his days as a student, they allready knew it wasn't a smart idea to use it, but they didn't have much better back then. Try/catch was still years away and error handling hardly excisted.
So what did you do to check your program? Add a few lines at the end that allow you to print output and everything you need to check in your code, and then you place the line: "goto printing;", or something like that, to start the printing of your data.
And in this manner, you gradually debugged your code.
He agrees that the use of goto in the modern programming world is pretty useless. The only use he finds justified is an "emergency break", to be used in extreme debugging and unexpected situations. Kinda like goto fatal_error;, and have the "fatal_error" part of your code do some things to show you in-depth results.But only during the creation of something. A finished product should not have goto-statements.
LATE EDIT: Another discussion about "goto" in PHP5.3/PHP6
If you're writing good PHP code, you shouldn't need to use goto. I think it's a mistake that they're adding it in, as it just leads to lazy programming.
See
http://www.procata.com/blog/archives/2004/07/29/goto-in-php/
For a good commentary on the addition of this to PHP, and also, here on stack overflow,
GOTO still considered harmful?
I have only ever found two uses for goto:
To break out of nested loops. But most newer languages have a mechanism to do this without goto anyway (break <number> in PHP, or break <loop label> in Java, etc.).
To go to a cleanup section at the end of a function. But again, this isn't often useful in a garbage-collected language.
In other words, if you don't know whether you should use goto for something, you shouldn't.
The main use I see in having gotos in a language is the ability to port across languages. I wrote a parser generator in C that generated parsers with gotos (because it was easier to use gotos than to implement more sane control structures), and now porting it to PHP isn't as much of a headache.
goto can help reduce code duplication for stack unwinding, in pseudo code below:
do A
if (error)
goto out_a;
do B
if (error)
goto out_b;
do C
if (error)
goto out_c;
goto out;
out_c:
undo C
out_b:
undo B:
out_a:
undo A
out:
return ret;
( Pseudo code by Robert Love, taken from the linux kernel archive mailing list: https://lkml.org/lkml/2003/1/12/203 )
It can be used for debugging purposes so you don't have to comment out or refactor blocks of code just to temporary change the workflow.
In Classic VB coding, use of goto is handy for emulating try/catch error handling like this:
Function MyFunction() as String
'-- start of error block
'
On Error Goto Catch
' do something here that might cause an error
MyFunction = "IT WORKED"
Exit Function
Catch:
' error occured - do something else
MyFunction = Err.Description
'
'-- end of error block
End Function
... and here is a way to emulate the try/catch/finally ..
Function MyFunction() as String
'-- start of error block
'
On Error Goto Catch
' do something here that might cause an error
MyFunction = "IT WORKED"
Goto Finally
Catch:
' error occured - do something else
MyFunction = Err.Description
Err.Clear
Finally:
' put your finally code here
'
'-- end of error block
End Function
It can also be useful for cleanup at the end of a function, although i suppose you could make a case that another function can be called to do that cleanup.
In all honesty, I have never had an occasion in PHP where I thought to myself 'hmm, I wish there was a goto statement'. I haven't read up on why they decided to do this, but, those guys are pretty smart, and have taken PHP into very good directions so far, so maybe the are anticipating a need that we don't realize yet.
There is no such thing as good use of goto.
Maybe, just maybe, it could be useful to get out of multiple nested loops, but you can already do that using "break 2" and such. Labeled breaks like in Java would be better than goto for this purpose.
Perhaps it's also useful with code written without using exceptions, when you need to skip to the end of a bunch of statements once one fails. But that's only fixing crappy code with more crappy code.
I admit I have never used goto in my codes. :)
The only reason for me seems to facilitate the shortest migration route from other languages to PHP (practically only changing the language without touching the control structures) and refactor the code on the 2nd stage of the porting.
Personally I believe in educated colleagues and as they can avoid the conditional break-s from loops, they would be able to resist the temptation of goto.
Goto is primarily used when writing finite state machines. When parsing context free grammer you will actually need one of those. Though we could live without goto if continue $case; is a valid statement within a switch block to jump to a different case and off course having case ranges as many languages nowadays have. Until then we are pretty much stuck with goto.
Sometimes I use goto to avoid multiple nested ifs. That's not only about the logic, the structure or the program flow, sometimes it can be just about how the code looks like.
Generated code could make good use of goto, I guess. The good thing about generated code is that you don't need to maintain it - you just regenerate it.
goto should really be something though that was in the language and would be being made obsolete due to better programming practises. Adding it now does seem like a backwards step.
The b big advantage of gotos is learning curve. One wonders why tools like visual studia and macs do well. The reason is that people want more than a great product; they want a
great product that they can learn to use in just an hour or so. Many programmers now
a days only program as one of their jobs. I see so many books say that one should never
use a goto and then give five or so technologies such that they say eliminate every
need of it. I say that just that fact that they mentioned 5 is proof of how good the goto
is!!!!! I don't have time to teach five things that include exception structures that
take whole chapters to explain!!!!! when all you really need is a simple goto that
can be explained in 30 seconds. Sure, you can create bad code with them if the
programmer wants--- but hey, most programmers don't want to write bad code and if they
did they could anyway. Most gotos in our lab made the code extremely simple to
understand and learn; much more so than reading a 2000 page book.
GOTO, the restricted execution control structure, can be used in the place of loops, but that is highly discouraged. Its use tends to encourage the creation of unstructured code, which is a terrible practice. It is most likely best if used only in development, for debugging (skip large amounts of code to access a particular problem area) and testing. The only other purpose for the GOTO is possibly for writing an assembler; not likely. GOTO, if used outside of development, should be used sparingly and only as a last resort. If possible, replace a GOTO with an applicable loop structure.
As for the thread linked last (GOTO command in PHP?):
As stated by Ishmaeel (edited by Gordon; by far the best answer):
The GOTO is simply an extended BREAK, with the ability to "use static labels".
"Basically, it will be enhancing the ability to break out of nested if statements."
The short answer is goto is a workaround for a limited stack space with much better performance in single threaded code. Other than addressing stack space or performance, its usage would be at least unnecessary and at most inappropriate because it causes unneeded complexity.
In over 2 million lines of code I've written in all languages, excluding machine code :-). Only twice has its use been necessary and both due to inspecting\sorting large tree datasets.
As has been said before, goto is only really required in some types of algorithms, usually those that come up in language parsing or finite state machines. I have never missed the lack of goto in PHP.
OTOH, I have programmed in a language where the only two structures were functions and conditional gotos: SNOBOL4. Since the risk of spaghetti code was so high, most SNOBOL4 programmers were/are careful to avoid that. But gotos did enable some very tight programming, creative loop executions and so on. It's actually somewhat easier to do FSM-type loops if all you have are gotos.