I worked once in a company which had this tourist app which should show places on map of the city. Unfortunately it slowed the App down to load more then a couple of places. Their solution was to limit the number of loaded places to teb and prohibited zomming out. I made it handle thousands of places at the same time. Main reason for the Performance issue was, that they sent all data they had about places big, big json objects with large text blobs) to the frontend. This part was easy, I instead sent only the data needed for the map like coordinates and icon type obviously. But still the backend struggeled hard with many objects from the DB, because they built a really shitty orm or what ever this was supposed to be: every line of data retrieved from the DB was immideatly wrapped in some class wich direved from another class which had some magic methods in it which caused some absurd loops over all other obejcts and even more DB queries in unexpected moments and also in the fucking constructor. So it turrned out that the map issue was only the top of the iceberg, since using any data from the DB was extremely expensive. The hard part was to understand the insaness of this abnormination and find the bottlenecks.

  • 4
    So much in modern coding results in abysmal performance. It's as if people no longer think efficiency matters, whereas I'm of the opinion that it's fundamental.
  • 5
    Often the case when we depend to much on abstractions and tools.

    Orms are good for fast implementation and consistent access but at least someone on the team should know it inside and out to be able to fix and optimize queries that does not work the way you need.

    Orms are not magic, for small data sets they will usually always be good enough, but for large, complex or uneven data sets you might need to tweak the usage or build some custom handling to get around problems, or maybe its even the actual table structures that needs to be redesigned.

    Bad DB design can break anything beyond repair.
  • 2
    @ultrageoff nothing of this had to do with modern progamming i'd say. Conversely is was a product of stickig to hard to the good old oop paradigm.
  • 2
    @horus Ah, that's quite funny - I was thinking OOP was the problem, but I was also thinking OOP was modern! Lots of jungles loading along with the monkeys holding the bananas that were actually needed, as the analogy goes? OOP and MVC were certainly a requirement in just about every job ad posted a year or so back. Personally, I use no routing, some classes and a limited amount of inheritance for dbObjects. Vanilla CSS, HTML5 inputs. Views forward to -exec pages with the same name. Easy.
  • 0
    Fair point, depends in what you see as modern.
  • 4
    I'm 60yo, so 'modern' would def include the www, more than five TV channels and telephones you can walk around outside with... Oh, and functional programming, whatever that is :-)
  • 4
    @ultrageoff but functional programming has been around for quite awhile with for example erlang that was developed 1986-87 or lisp that started out in 1950 :)
  • 3
    It's not the ORM's fault. Not directly. I mean it explains it in the documentation. Just... nobody reads it.
Add Comment