Web Application VS Windows Application
-
@IT-ADMIN said:
... after doing some researches i found that ORMs hurt performance too much,
I have to say, this is a silly statement. ORMs are not all the same thing and do not do things in the same ways. Experience with one gives you no experience with another. ORMs are pretty much the only means of writing software today. Any extra layer will add overhead, of course, but two seconds of overhead? No, something is wrong. Either there is a code problem here, or a caching one, or a misunderstanding of what is happening or just a bad framework (I don't know this one, I can't comment on it.)
ORMs are used in basically all enterprise software at all levels and have been for an extremely long time. In many cases they can even be faster than not having an ORM because they can do things like caching queries to speed things up that you would have to write by hand.
Think about this website (MangoLassi). Are you waiting two seconds for the system to respond? But it has millions of records and hundreds of thousands of users. Clearly the ORM is not adding the kind of overhead that you are worried about. The responses are instant. And this system has less memory and CPU than yours does.
So having an ORM is not the issue. The wrong framework perhaps, or not knowing how to use it correctly. Or a database not designed to work with it. But do not jump to the conclusion that having an ORM is the issue, it is not and there is no logical connection between what you have observed and that conclusion.
-
@IT-ADMIN said:
@dafyre how you manage this issue of performance ??
I've never encountered a situation where the ORM introduced noticeable performance, it's not something you normally need to manage outside of extremely high performance databases (like those with four dedicated CPUs, 256GB of its own RAM, etc.), many TB in size, etc.
-
ok, i see what you mean, i think only this ORM is not efficient, it is nothing but one php file that has so many functions ready to use (about 12000 line of code), so when i call a function for example, the php code has to scan this big php file which i guess it is the root cause of this late, i have to check other ORM
thanks
-
@IT-ADMIN said:
ok, i see what you mean, i think only this ORM is not efficient, it is nothing but one php file that has so many functions ready to use (about 12000 line of code), so when i call a function for example, the php code has to scan this big php file which i guess it is the root cause of this late, i have to check other ORM
Yes, a PHP ORM would have performance issue simply because PHP is not that performant without further systems to help it. There are several ways to improve this, from Facebook's real time compiler, some caching mechanisms or just moving to PHP 7. But at the end of the day, a PHP library isn't likely the most ideal mechanism for an ORM. Many languages are real time compiled so once loaded, the ORM is very, very fast just because of that.
-
@IT-ADMIN said:
good morning guys
@dafyre: i tried redbeansPHP, it make the DB manipulation very easy, but i have problem, the performance is dramatically reduced, before for example when i display all records of a specific table it displayed immediatley, now after using RedBeansPHP, it take about 2 sec to display the table even if this table contain about 20 record, i wonder if this table contains 200 record maybe it will take 4 sec, after doing some researches i found that ORMs hurt performance too much,
@dafyre how you manage this issue of performance ??I don't seem to have the issue with performance that you do. My searches and results are near instant (I have a test database with ~1000 records and ~10 or 15 fields with data in them).
I get about the same performance using RB4 that I do if I write the code to work with the database myself.
-
@scottalanmiller said:
@IT-ADMIN said:
ok, i see what you mean, i think only this ORM is not efficient, it is nothing but one php file that has so many functions ready to use (about 12000 line of code), so when i call a function for example, the php code has to scan this big php file which i guess it is the root cause of this late, i have to check other ORM
Yes, a PHP ORM would have performance issue simply because PHP is not that performant without further systems to help it. There are several ways to improve this, from Facebook's real time compiler, some caching mechanisms or just moving to PHP 7. But at the end of the day, a PHP library isn't likely the most ideal mechanism for an ORM. Many languages are real time compiled so once loaded, the ORM is very, very fast just because of that.
I need to upgrade my application's development environment from XAMPP to CentOS + Nginx + PHP7 to see what kind of performance gains I can get.
-
@dafyre said:
@IT-ADMIN said:
good morning guys
@dafyre: i tried redbeansPHP, it make the DB manipulation very easy, but i have problem, the performance is dramatically reduced, before for example when i display all records of a specific table it displayed immediatley, now after using RedBeansPHP, it take about 2 sec to display the table even if this table contain about 20 record, i wonder if this table contains 200 record maybe it will take 4 sec, after doing some researches i found that ORMs hurt performance too much,
@dafyre how you manage this issue of performance ??I don't seem to have the issue with performance that you do. My searches and results are near instant (I have a test database with ~1000 records and ~10 or 15 fields with data in them).
I get about the same performance using RB4 that I do if I write the code to work with the database myself.
The query itself is far more of a factor than the size of the database.
-
@dafyre said:
@scottalanmiller said:
@IT-ADMIN said:
ok, i see what you mean, i think only this ORM is not efficient, it is nothing but one php file that has so many functions ready to use (about 12000 line of code), so when i call a function for example, the php code has to scan this big php file which i guess it is the root cause of this late, i have to check other ORM
Yes, a PHP ORM would have performance issue simply because PHP is not that performant without further systems to help it. There are several ways to improve this, from Facebook's real time compiler, some caching mechanisms or just moving to PHP 7. But at the end of the day, a PHP library isn't likely the most ideal mechanism for an ORM. Many languages are real time compiled so once loaded, the ORM is very, very fast just because of that.
I need to upgrade my application's development environment from XAMPP to CentOS + Nginx + PHP7 to see what kind of performance gains I can get.
NGinx should not make a difference. but PHP7 should be enormous.
-
@scottalanmiller said:
@dafyre said:
@scottalanmiller said:
@IT-ADMIN said:
ok, i see what you mean, i think only this ORM is not efficient, it is nothing but one php file that has so many functions ready to use (about 12000 line of code), so when i call a function for example, the php code has to scan this big php file which i guess it is the root cause of this late, i have to check other ORM
Yes, a PHP ORM would have performance issue simply because PHP is not that performant without further systems to help it. There are several ways to improve this, from Facebook's real time compiler, some caching mechanisms or just moving to PHP 7. But at the end of the day, a PHP library isn't likely the most ideal mechanism for an ORM. Many languages are real time compiled so once loaded, the ORM is very, very fast just because of that.
I need to upgrade my application's development environment from XAMPP to CentOS + Nginx + PHP7 to see what kind of performance gains I can get.
NGinx should not make a difference. but PHP7 should be enormous.
I can tell a big difference with ownCloud + PHP 7 (Nginx) vs ownCloud + PHP 5 (Apache).
PHP7 is the real winner in that arena.
-
@dafyre said:
@scottalanmiller said:
@dafyre said:
@scottalanmiller said:
@IT-ADMIN said:
ok, i see what you mean, i think only this ORM is not efficient, it is nothing but one php file that has so many functions ready to use (about 12000 line of code), so when i call a function for example, the php code has to scan this big php file which i guess it is the root cause of this late, i have to check other ORM
Yes, a PHP ORM would have performance issue simply because PHP is not that performant without further systems to help it. There are several ways to improve this, from Facebook's real time compiler, some caching mechanisms or just moving to PHP 7. But at the end of the day, a PHP library isn't likely the most ideal mechanism for an ORM. Many languages are real time compiled so once loaded, the ORM is very, very fast just because of that.
I need to upgrade my application's development environment from XAMPP to CentOS + Nginx + PHP7 to see what kind of performance gains I can get.
NGinx should not make a difference. but PHP7 should be enormous.
I can tell a big difference with ownCloud + PHP 7 (Nginx) vs ownCloud + PHP 5 (Apache).
PHP7 is the real winner in that arena.
I've heard it is 40% speed boost on average!
-
@scottalanmiller said:
@dafyre said:
@scottalanmiller said:
@dafyre said:
@scottalanmiller said:
@IT-ADMIN said:
ok, i see what you mean, i think only this ORM is not efficient, it is nothing but one php file that has so many functions ready to use (about 12000 line of code), so when i call a function for example, the php code has to scan this big php file which i guess it is the root cause of this late, i have to check other ORM
Yes, a PHP ORM would have performance issue simply because PHP is not that performant without further systems to help it. There are several ways to improve this, from Facebook's real time compiler, some caching mechanisms or just moving to PHP 7. But at the end of the day, a PHP library isn't likely the most ideal mechanism for an ORM. Many languages are real time compiled so once loaded, the ORM is very, very fast just because of that.
I need to upgrade my application's development environment from XAMPP to CentOS + Nginx + PHP7 to see what kind of performance gains I can get.
NGinx should not make a difference. but PHP7 should be enormous.
I can tell a big difference with ownCloud + PHP 7 (Nginx) vs ownCloud + PHP 5 (Apache).
PHP7 is the real winner in that arena.
I've heard it is 40% speed boost on average!
That could easily match what I'm seeing. Although migrating from C@C probably has something to do with that too, lol.
-
@dafyre said:
@scottalanmiller said:
@dafyre said:
@scottalanmiller said:
@dafyre said:
@scottalanmiller said:
@IT-ADMIN said:
ok, i see what you mean, i think only this ORM is not efficient, it is nothing but one php file that has so many functions ready to use (about 12000 line of code), so when i call a function for example, the php code has to scan this big php file which i guess it is the root cause of this late, i have to check other ORM
Yes, a PHP ORM would have performance issue simply because PHP is not that performant without further systems to help it. There are several ways to improve this, from Facebook's real time compiler, some caching mechanisms or just moving to PHP 7. But at the end of the day, a PHP library isn't likely the most ideal mechanism for an ORM. Many languages are real time compiled so once loaded, the ORM is very, very fast just because of that.
I need to upgrade my application's development environment from XAMPP to CentOS + Nginx + PHP7 to see what kind of performance gains I can get.
NGinx should not make a difference. but PHP7 should be enormous.
I can tell a big difference with ownCloud + PHP 7 (Nginx) vs ownCloud + PHP 5 (Apache).
PHP7 is the real winner in that arena.
I've heard it is 40% speed boost on average!
That could easily match what I'm seeing. Although migrating from C@C probably has something to do with that too, lol.
Um, yeah.
-
When you are ready for another insane leap in speed, move from things like MySQL to things like MongoDB.
-
Speaking of insane leaps, do you guys have any source content for SQL best practices?
-
@scottalanmiller said:
When you are ready for another insane leap in speed, move from things like MySQL to things like MongoDB.
I'm looking into that. I can see things like what I am tinkering with in my spare time being quite useful in a MongoDB type setup... I just need to figure out how to structure the data for it.
-
@wirestyle22 said:
Speaking of insane leaps, do you guys have any source content for SQL best practices?
"Best Practice", if you can call it that, is to not use relational databases for most workloads (say 60% of them) and when you do to abstract it with a good ORM and not write SQL yourself. Using relational databases should not be an assumption and interacting with it directly should be very special case.
-
please anyone tell me whether this guy is right or not ??
http://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.htmlhe smash the whole concept of ORM, what the hell is this ????
-
@IT-ADMIN said:
please anyone tell me whether this guy is right or not ??
http://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.htmlhe smash the whole concept of ORM, what the hell is this ????
I feel like you are desperately looking for justification for hand coding SQL. It's a silly thing to be talking about. What is your goal here? If you don't want to use an ORM, don't use one. Don't waste time coming up with wacky people complaining, you can always find someone that will rant about anything that you want. Obviously this guy doesn't agree with the industry. Do you know him and trust him. If not, why are you reading his article?
-
One of his key issues is that ORMs are difficult to test. Are you doing test driven development? What kind of testing are you doing?
-
Did anyone notice that the complaint at the end wasn't that ORM was bad but that he didn't like Hibernate and his solution was to.... make a new ORM that he shows how to implement?
