I purchased a very large script many years ago from Josh ( I recently found out that he is also known by another name? ) for a pretty penny. One of the functions listed I have been rebuilding to suit my needs. I could use another set of eyes and perceptions to find faster functionality. I have decompressed the function and expanded to make easier reading ( Sorry for the mess in advance! )

- Code removed — proprietary content from a paid script -


I have been going through each function and benchmarking, attempting to find the fastest methodology. And example would be $user=json_decode('['.$user.']', true); is faster that $user=explode(',',$user);

I also need to fully incorporate object parsing within the function to bypass additional functions, as well as incorporate NationalID Regexes, Passport Regexes ( we also have to eventually include a fingerprint Regex at some point, but that is outside of my scope of experience ).

Anyone willing to give feedback, question any methodology, or overall critique, I would be more than willing of sharing the final product of this function.

An example in question would be, which of these methods would be faster:

As best as I can tell, if( !empty() X3 ) is faster, however at what point of multiple key checks does it become more efficient to use !(empty(array_filter()) ???

I hope you realize that code was not even close to its original, just as Josh had taken the Evo Version of the same function and extended it. Just as I am taking the function and extending it ( I need a lot of additional tables of data into the USER, as well as USER_IDs can never be (int). However, that function does work with evo ( Change the SQL Fields ), as it was originally built for.

PS: The SQL Fields were changed to a schema layout to allow for remote update insertion.

As for the important parts: Originally, this function was designed to cap at 10k, which requires chunk loading from an even larger array. My goal is to increase the speed to match due user_id never being an int, and string parsing never being allowed.

The Speed, comes in two parts:
1) the SQL Query itself. However, due the nature of the information being requested, the "bare bones" would take priority. Meaning the initial would remain removed to sacrificing dynamics for a speed. HTTP_BUILD_QUERY( is faster than EXPLODE(, but both are slower than hard coded definitions to remove the function calls.

2) The second, and most important part is the removal of as many function calls as possible. As best as I can tell, this results in increased Memory usage. in_array is manually bool var set after it's initial check. The entire goal is to squeeze 300ms off the function.

— Doug wrote

I removed this code because it came from a paid script, as mentioned. Even though it was just a single function, I want to respect the original author's rights and avoid sharing any part of their work without explicit permission, regardless of who created it.

-coRpSE

This specific function ( well, the original ) is publicly shared on GitHub.

— Doug wrote

This specific function ( well, the original ) is publicly shared on GitHub.

You need to lead with that type of info instead of:

— Doug wrote

I purchased a very large script many years ago from Josh ( I recently found out that he is also known by another name? ) for a pretty penny. One of the functions listed I have been rebuilding to suit my needs. I could use another set of eyes and perceptions to find faster functionality. I have decompressed the function and expanded to make easier reading ( Sorry for the mess in advance! )

That implies it wasn’t a "public" function and was from a paid script. I try to stay away from paid scripts to avoid drama from other developers upset about their code being altered or publicly shared without their explicit permission. (This all stems from my ClanThemes days).

The "paid script" was an incredibly large CMS, with a sniffer backend that took user information like an email, and then scraped known social media accounts ( Twitter, Facebook, LinkedIn, exec, exec ) and searched for secondary "alt" accounts. It was 95% accurate, but that 5% of false triggering was an annoyance that required human overwatch.

This function ( and several others ) were public release functions. Josh did have an ego and liked sharing with people he collaborated with, and I believed enjoyed the competition.

The original function is based on user_ids from a database being (int) format, which is not compatible with MLS Databasing simply because too many attached tables are also (int), and the user primary key is always a string of exactly 9 characters in length. This factor alone is what allows the function to tolerate inputs of different more than just 4 types of input formats