Although both are interpreted languages there are differences or?
What are the performance differences of both languages? Even if Perl would be faster than PHP, the most would choose PHP, because of the simplicity of PHP. Does someone have experience in this regard?
The Computer Language Benchmarks Game compares several programming languages.
There is quite a lot of information on this which is easily available.
Took about 1 minute on Google to find these hits and a few more ...
Edit: By the way; is there a particular problem you're trying to solve? I think it will be easier to get a good answer if you give an example :)
First, you have to define what you mean by "performance", and how much you're willing to give up to get that.
Most people would tell you that this means something like "completes the task the fastest". That's not very interesting though. If you wanted a really fast solution, you shouldn't be using either PHP or Perl. You want to get as close to the bare metal as possible. Higher level languages waste a lot of time because they are general purpose tools. They have to be ready to do anything, not just what you want to do. As such, they give up some speed for flexibility.
Oh, but programming at such a low level takes too long and isn't portable. So now you have to factor in the development time it takes you to get to the point where you program is merely acceptably fast. If it completes in the blink of an eye, do you need need it to finish in half a blink? Maybe a high-level language is sufficiently speedy.
Some people will tell you Perl (or some other language) is really easy, and it is for the experienced programmer. That doesn't help you if you don't know Perl yet, though. The language doesn't really matter. If you know PHP but not Perl, maybe you can have a PHP solution tonight. If you go through my Learning Perl book, which a reasonable person can do in about 40 hours if they do all of the exercises, maybe you have a Perl solution in two weeks. Vice versa, a person with reasonable Perl skills might have a Perl solution tonight, but a PHP solution in a week. That extra developer time might not be worth it.
A common problem I see with any sort of programmer, however, is the root cause of most inefficiency: they simply don't know how to program and neither do they care. Sure, they can make a syntactically valid program, and they can string together a series of Rube Goldbergesque statements that eventually give the desired effect, but they don't know how to design, make efficient use of resources, and so on.
Once such pretender I had to evaluate insisted that the company buy more hardware despite CPU utilization never topping 5%. He made huge in-memory hashes to configure everything, taking up 500 MB per hash and running on 16 apache child processes. His very simple program to upload a file and put it in a database was constrained by the physical amount of RAM in the machine. His performance was really low because he didn't know what he was doing. That he was using Perl didn't matter.
Indeed, a now deleted answer on this site used 16GB to generate 100 random numbers. If you know how to design programs, you're not going to do stupid things like that in any language.
Some people like to point at benchmarks for toy programs. The problem is that you're never interested in writing toy programs, so the benchmarks are irrelevant. Tim Bray ran a Winde Finder competition, and try as he might to make a Ruby or Erlang solution come out on top, Perl took the prize. Don't get too excited about that though. Notice that the top 20 solutions came from only a handful of people, and that most languages also had very poor solutions. Some of the top solutions were in Erlang, even though Tim himself wasn't skilled enough in Erlang to get those results (and he's no slouch, mind you). He also notes that the Ruby solutions ran faster on a Mac laptop than they did on Sun's T5120. Not only that, but many of the top solutions, no matter the language, used the same technique: they mmapped a file. The programs were basically the same. Getting the picture yet? The programming language isn't even close to being the important decision.
Now maybe some people start to see the productivity angle: how much do I have to put in for what I get out? Many of my Perl colleagues will scoff at PHP, make snide remarks about its design, and so on, but they completely ignore the fact that for some basic things, you have to put in very little to get out what you need. However, they are probably right that you sacrifice a lot tying yourself into PHP's model. Maybe PHP gives you a short-term win, which is completely valid, but betting the farm on it might not be the right long-term solution, say, when you want to move to web services instead of web pages (I'm looking at you, Sourceforge).
And it just keeps going on from there. You have to figure out what you want for "performance", figure out how all of your choices impact that, then choose the solution that's right for you. That's a long way to say that no one can answer this question for you, and that even for you, the answer might change based on new requirements.