Found in the code base at work



  • I found this yesterday. I was... amazed but not surprised.

    ini_set("memory_limit", "3072M");
    

    The script actually does require that, but only for the usual reason.



  • memory not used is memory wasted.



  • So why do they say "waste not, want not"?


  • Winner of the 2016 Presidential Election

    @Arantor said:

    ```
    ini_set("memory_limit", "3072M");

    
    TRWTF is that Discourse thinks this is a Bash script. Also, I can't quote your post without inserting a blank line before the code block. <small><small><small><small><small><small><small><small><small><small><small><small><small><small><small><small><small><small>@discoursebot


  • @Arantor said:

    So why do they say "waste not, want not"?

    people say things and stuff all the time.



  • @asdf - Days Since Last Discourse Bug: 0



  • @Arantor said:

    The script actually does require that

    PhpExcel?


  • BINNED

    @Keith said:

    PhpExcel?

    I have never used that but I still have this sudden urge to kill it with fire...



  • @Keith said:

    PhpExcel?

    Some men just want to watch the world burn.



  • It's useful, but it's a memory hog.


  • BINNED

    @Keith said:

    It's useful, but it's a memory hog.

    I'll stick to fgetcsv, thanks.



  • @Arantor said:

    I found this yesterday. I was... amazed but not surprised.<invsible tag discofixes formatting>

    ini_set("memory_limit", "3072M");
    

    The script actually does require that, but only for the usual reason.

    I thought it was worth checking what that's intended to do, because, well, PHP.
    It seems straightforward enough... 3GB is quite a lot of RAM upfront, but there are fields of application where you might need it (e.g. a fluid simulation).

    I did find this though...


  • BINNED


  • Grade A Premium Asshole

    @asdf said:

    TRWTF is that Discourse thinks this is a Bash script.

    Discourse cannot even parse its own shit, you think it can discern random code snippets? ;-)



  • @Keith said:

    PhpExcel?

    Reminds me of a PHP-based web app I’ve seen at one of my previous jobs, which was generating Excel files by programatically controlling Excel though COM.


  • BINNED

    @VinDuv said:

    generating Excel files by programatically controlling Excel though COM.

    :facepalm:

    First emojicon suggestion is also acceptable: :facepunch:



  • To answer the question about what this is doing... it does require 3GB because retardary is a thing.

    This script sends batches of emails from the database. Query to get the list of users, for each row kick off a query to get their preferences, then kick off another query based on the preferences... it's loops of queries all the way down.

    And calling mysql_free_result is a new idea to them.

    There's also another file that builds Excel files - though thankfully not with COM since the production webservers don't have Excel on them. They did nearly get OpenOffice on them though.

    EDIT: Yes, that other script uses PhpExcel. That one only requires 2GB RAM, too.



  • @Arantor said:

    This script sends batches of emails from the database. Query to get the list of users, for each row kick off a query to get their preferences, then kick off another query based on the preferences... it's loops of queries all the way down.

    OK, so it's the fact that these queries weren't properly linked into one thing and not a php stupid. Did you fix it to just link the queries into a single block of returned stuff?



  • COM is a good thing in my opinion, not worthy a wtf.

    In the topic list, I always misread the title of this topic as "Found the code base at work"



  • @marczellm said:

    COM is a good thing in my opinion, not worthy a WTF

    Having Excel on a server IMO is, though. We're just migrating our codebase from that to NPOI (which has a million of quirks and the documentation is 90% StackOverflow, but when it works, it works).

    Not sure if there's a .xls(x) proper parser for PHP, though.



  • @Maciejasjmj said:

    Having Excel on a server IMO is, though.

    Agreed. The mere thought of Excel.DisplayAlerts = False is creepy.



  • I didn't say it was a PHP stupid. It is the fact that the script is so badly written that it requires 3GB to send, maybe, 200 emails...

    Have I fixed it? Nope. There are far larger fuck-ups to fix than this one, and I don't have any time budget to fix any of them since everything I'm doing is new feature development.

    I did however fix the admin panel to use 1800 less queries per page because querying for a menu, querying for every single item to see if there are sub items, followed by querying for every single item to see if a master toggle switch has been turned off is a shade inefficient.

    Or performing a lookup on the language tables, once per time they're used. Maybe 100 uses on a page, one query per.

    These things were quick and dirty fixes and had a visible performance improvement, not hard to justify that sort of thing. But this is hard to justify.

    I still have to write up the full horror of what I'm dealing with here, too.


  • Discourse touched me in a no-no place

    @Arantor said:

    There are far larger fuck-ups to fix than this one

    :wtf:


  • BINNED

    @Arantor said:

    There are far larger fuck-ups to fix than this one

    How do you...

    @Arantor said:

    I did however fix the admin panel to use 1800 less queries per page

    1800.. wh...

    @Arantor said:

    querying for a menu, querying for every single item to see if there are sub items, followed by querying for every single item to see if a master toggle switch has been turned off

    :facepalm:

    I saw this shit all over the place, but php applications are where I saw it the most. Construct a decent query FFS. Having a few duplicate values in your results can't be as bad as looping over every single fucking array. And then querying again in each iteration!

    @Arantor said:

    I still have to write up the full horror of what I'm dealing with here, too.

    Expectations are high, given the source and the language involved 😆



  • @Arantor said:

    I didn't say it was a PHP stupid. It is the fact that the script is so badly written that it requires 3GB to send, maybe, 200 emails...

    That, my dear Arantor, is really a lot of memory. I think even PHP could hold 200 emails in memory without requiring more than 1MB. 3000MB is ... surprising.

    Have I fixed it? Nope. There are far larger fuck-ups to fix than this one
    Is there a "I have difficulties believing what I just read but only because I would like so much for the world to be a nice place, even for PHP programmers" emoticon? Preferably a mulatto person thinking that.


  • @Arantor said:

    Have I fixed it? Nope. There are far larger fuck-ups to fix than this one, and I don't have any time budget to fix any of them since everything I'm doing is new feature development.

    Maybe you could phrase "not use absurd amounts of resources" as a feature? Needing to use that much to do basic things means that there must be a lot of capacity wasted that could be saved if they made things not suck so bad.


  • BINNED

    @Hanzo said:

    I have difficulties believing what I just read but only because I would like so much for the world to be a nice place, even for PHP programmers

    There is no joy. There's only painUtil. Or is it util_pain? Or pain_util?

    I'll get back to you on that, need to check docs. Again.


  • I survived the hour long Uno hand

    I think it's real_toThePain


  • BINNED

    Ooooh, right, php 5.4. I was thinking of 5.3.9.

    Fuck it. Doesn't work. PHP. PHP never changes.



  • I thought it was util_realpain or utili_realpain.

    Of course, you should be using PDU.


  • BINNED

    @powerlord said:

    Of course, you should be using

    I work with PHP. Of course I am.



  • Discourse was being funky earlier. I had to submit it 3 times before it actually posted and apparently it decided that it should just remove the last part of my post (first submission it was UDO, second submission it was PDU... should have still been PDU in the third submission but Discouse!)


  • BINNED

    I figured it was something like that. Couldn't let that one go though. Too easy :P



  • @marczellm said:

    COM is a good thing in my opinion, not worthy a wtf.

    It has far outlived its usefulness.

    The only time COM is useful, is when the program you want to communicate with, chose COM as its method for interfacing, and you don't have access to its source.



  • @marczellm said:

    COM is a good thing in my opinion, not worthy a wtf.

    Thing is, Office likes to go "oh, blurf, I don't know :wtf: is going on, let's pop a dialog box!" When running on a server, your COM Automation app doesn't have a way to prevent said dialog box from popping up, and said dialog box's modal loop has no clue what COM Automation is...

    :headdesk:



  • This puts me in mind of one of my first "big" contracts back in the 00s, which was for a PHP backend. The client didn't know what they really needed, so they offered to pay me ~$5000 (I forget the actual original numbers) if I could speed up their admin pages to load and run in half the time, with a $500 bonus for each extra multiplier I could squeeze out in performance. They set me up with some admin credentials and I logged in... and about thirty seconds later was treated to a super ugly giant form page with I don't know how many fields. As it turns out, each section of the form was opening a new DB connection and running queries for the info which were in-page. One query per form item. At 40+ sections on the page, this took some time.

    There was a similar WTF with the form's save method, but I can't remember what it was. In any case, I retooled the thing to use a single connection and load each section from one stored procedure (most of which were simple things like "all the info for this user"). Page load time went down to about a second and save times to near instantaneous. They wound up paying me about 8k, IIRC, for what must've been a whole day worth of work... maybe two, since I did have to read the ugly source to figure out what was going on.

    PHP can be kind of crap, but most of the time it's the original coder who's TRWTF.


  • Discourse touched me in a no-no place

    @VaelynPhi said:

    most of the time it's the original coder who's TRWTF

    True, or the maintenance mook that had it between the original programmer and you.


Log in to reply