is it possible to remove array positions with `arr...
# cfml-general
s
is it possible to remove array positions with
arrayMap
? The reason for the question is i would like to filter an array of structs and also return a single column while getting the benefits of async
a
What about a reduce? I think that's probs more idiomatic than an each?
Copy code
fewerSimpler = more.reduce((fewerSimpler, el) => {
    if (el should be filtered) {
        return fewerSimpler
    }
    return fewerSimpler.append(el.thatOneColumn)
}, [])
?
s
reduce is way faster, and i dont know why
a
Oh reduce won't allow the async will it?
s
no
a
forgot that was part of the requirement
s
lol it turns out async was making it slower ๐Ÿ˜
dang thread startup time
a
yeah I think if you have heavy operations like a DB call / curl / etc then it'd help. But there's overhead with the threads. I'd never use it (or even worry about it) if the callback was just doing cfml stuff
if the callback would itself take like 100s of ms then... good usecase. If it's only taking a few ms then no point
If I was wanting to micro-optimise that sort of thing, I'd use a
for
statement instead of the fancy high order functions.
Or [not CFML]
s
why not cfml?
a
it's slow
s
slow relative to what kotlin? genuine question, for the most part i havenโ€™t experienced slowness
a
I was even thinking PHP
๐Ÿ˜‰
s
oh, please, i will gladly take the extra milliseconds to not program in PHP
a
What I more mean though is if one has some really chunky data processing to do, using a dynamically typed just-in-time compiled language designed for web sites is probs not the best option.
A parallel would be like to not get ONE MILLION (channelling Dr Evil) records from a DB and then perform data processing in CFML. Better to let the DB do the DP cos that's what it's for
I was not really encouraging "my language is faster than yours"
So just ask the question "am I doing this processing in the right place"
s
i see, yeah my use case is actually under 1000 rows and given it was being used multiple times i was trying to optimize its process
a
I am expected in the pub in 35min and it's 45min away. Must get to the station. Will be back online in a bit
๐Ÿ‘ 1
๐Ÿ‘๐Ÿผ 1
I would save that optimisation until there's an actual issue to address. "Make it work, make it right, make it fast" n'all
The latter does not need to be at the same time as the former two.
๐Ÿ‘๐Ÿผ 1
g
I like to make sure that I have "quality" code (for whatever that's worth because it is certainly subjective.) Then I optimize if there is a need. Sometimes it works out to be as simple as add an index to the DB. Sometimes it's a code optimisation. I default-ly use arrays in CFML because they are faster than lists... (and little changes like this - into your default solutions - cumulatively do make a real difference in processing speed.)
s
To expand on this thread, it turns out that premature optimization (using threading) turned out to be counterproductive and resulted in slower loading times. plus i ended up causing a race condition with it as well
g
As an "extra" - I am doing a Masters of Data Science at the moment and for millions of rows I would never use CFML. @Adam Cameron hit on it before - but I do think it needs emphasizing - CFML (while certainly much more capable / much more efficient / etc today) has been built upon the "premise" of creating dynamic content for the web. Even the changeover from Allaire's C++ version to Adobe wholly rewriting it to run on the JVM - was still dynamic web-based in philosophy. From genuine research... of my own and of standing on the shoulders of others - "graph" databases can be exponentially faster for select statements / searching, over a Relation Database. So I am a huge fan of graphs for massive data. Also I use tools / libraries designed from the ground up for data processing. My go to Stack for Data Science is; Spark, Mesos (kubernetes), Akka, Cassandra and Kafka - otherwise known as the SMACK stack. For the inquisitive, Spark is effectively Scala's Collection library (lists / arrays / maps / etc) rewritten for parallel and distributed processing. Scala was written by Martin Odersky who wrote the Java Generics - and felt there were fundamental issues with Java that couldn't be "readily solved" - so he created a whole new language - which allowed OOP AND functional programming in the same language. From a Scala "fanboy" perspective - your newest favourite Java function - was (genuinely - in the realm of 95% certainty) stolen from the Open-Sourced, Scala. (functional programming / Lambdas - truly heaps of "new" Java is from Scala @ 2 releases earlier. Much like Lucee plays catch-up (a lot of the time) to what Adobe puts in ColdFusion - Java follows the pioneering of Scala. Akka is an asynchronous library for implementing the Actor system (distributivity) - which was invented via Siemens in the 60's and is famous for Siemens ability to have seven 9's uptime. (99.99999%) And while all the pieces of the SMACK stack are their own presentation worthy topics - Akka (IMHO) is what makes the "stack" work. Cassandra - again is a distributed NoSQL Database and has (as an option) a truly awesome "graph" flavour - which earned it's creator a PhD. (Cassandra Graph - also comes with Spark embedded) And finally Kafka - is a data Streaming queue - invented at Netflix as they were getting too big to handle all their output as they started really taking off - and this also earned it's creator a PhD, too. I am a big fan of Functional Programming (Sadly I only get to use it in my studies at the moment) and I am subsequently a fan of Haskell - because you HAVE to write in a functional manner. Where as Scala lets you slip back into "old" comfortable solutions - because it does imperative as well. From a "real world - solution" perspective - "I" would use Scala - but while I am doing my degree - I use Haskell for all the coding that I can to enforce the FP mentality upon myself.