My best friend's sister's boyfriend's brother's girlfriend

My best friend's sister's boyfriend's brother's girlfriend

i hate pointers in C

programming bitching thread. scripting languages should get anally raped if they pop up.

Bump for perfection

>i hate pointers in C

pointers are the shit

By any chance an engineering student in belgium who has exam system software in an hour?

You fucked it up.

It's:

"My best friend's sister's boyfriend's brother's girlfriend..."

Douche.

Nope.

I'm the douche.

Carry on.

As a professional programmer who has worked with C for over 15 years I find this post confusing as hell.

Furthermore a good C program includes scripts in it. In fact it is made up of multiple languages.

Still I would only use C for very specific applications. I use Ada for anything important.

>i hate pointers in C
Get the fuck over yourself.

ITT pseudointellectual computer janitors try to form a clique with firstyear C

A pointer tells you what something is, and where to find it. What's to hate?

14 year-old script kiddie detected.

Itt wannabe's act like they know what they are talking about.

Hello government contractor. Working for FBI or NSA?

.

only 1337 hackers like us know what pointers are, eh user?

fucking idiot

Nah, I convinced my company to go Ada or bust. Best decision ever. I hated debugging an endless sea of C code. Now I only use it in specific situations which ultimately comes up here and there. Sometimes C++. Sometimes Java. Sometimes Assembly or VHDL. etc etc.

I thought is best not to comment directly - but to link it to your post.
- via this pointer . .. .
- because the language will update my pointer if you move your post.
- do you get it ?

>pointers
>can't clean up after themselves

Go back to mommy, you fucking plebs.

Any node.js loving faggots like me in here?

So like I'm writing this thing and I have an array of pointers and every 1000 program loop cycles I clean out the array, that is, any pointer within the array of pointers that has been free'd and set as NULL is then not included in the temporary array which consists of only non-NULL pointers.
The original array is then free'd and the temporary array is assigned to it.

Yet the performance keeps dropping anyway. Any ideas?

Is thread kill?

Why are you asking me, lol

Performance optimizing can be a complex task, especially in bigger programs where so many things can affect so many other things. It is one rule of optimizing that you avoid "cleanup" routines wherever possible. There is almost always a way to achieve that goal without actually babysitting memory. Think garbage collection, except at a more localized level with arrays. I'd give you a more detailed answer but you asked a relatively vague question.

Basically on a condition an element is inserted into array, this can happen every loop cycle at random periods of time.
These elements have a condition on which they expire. On that condition I free the pointer and set it to null in the array, so that on iteration I wouldn't run into a whatchamacallit segfault.
Problem with that is that the array expands ridiculously as there can be thousands of elements during the first few seconds of the program.
Second problem is that even after truncating(?) the array, i.e. creating a new one with no null elements performance still drops and I can't figure out why.

However, when the first mentioned condition is never satisfied performance does not drop.

First of all I hope you are scheduling your main loop nicely so that it does not overwhelm the system.

Secondly, perhaps a clean-up routine is not wise in this case. It sounds like you are trying to optimize for insert speed, but the cost is that your array's capacity and the application is working against that benefit.

I'd advise moving the clean-up closer to the function that no longer needs it perhaps as a callback function or event.

Or depending on how easy it is to identify an expired element you might just avoid cleanup alltogether and let the insert search for unused elements right then and there (partial cleanup on insert). It will take a performance hit at the insert but maybe now the application won't overwhelm the array.

Consider that you might also be going about this array all wrong. If it fills up this quickly you might want to consider not using an array at all, instead register pointers to objects to keep track of your memory so everything is self contained.

>First of all I hope you are scheduling your main loop nicely so that it does not overwhelm the system.

The performance drop is linear proportional to the progression of the expansion of the array.

>Consider that you might also be going about this array all wrong. If it fills up this quickly you might want to consider not using an array at all, instead register pointers to objects to keep track of your memory so everything is self contained.

I do that via a pointer to a block of memory that contains pointers to objects. malloc() and free().

>Or depending on how easy it is to identify an expired element you might just avoid cleanup alltogether and let the insert search for unused elements right then and there (partial cleanup on insert). It will take a performance hit at the insert but maybe now the application won't overwhelm the array.

That's suboptimal still. The point is to shrink the array so that iterating over it each loop does not take an increasingly large amount of cpu cycles or time.

>I'd advise moving the clean-up closer to the function that no longer needs it perhaps as a callback function or event.
The time it would take to get to that function is indefinite and for current purposes considered that the main loop is infinite.

ok faggots tell me what this is:

>char *(*(**foo[][8])())[];

...

its clearly a pointer

foo is an array of arrays of 8 pointers to pointers to a function returning a pointer to an array of pointers to char.

well that was easy

>The performance drop is linear proportional to the progression of the expansion of the array.

Expansion? I didn't know you were expanding the array. How much are you expanding when a new element is inserted?

>I do that via a pointer to a block of memory that contains pointers to objects. malloc() and free().

Eww. Do not malloc() and free() more than you need to. Pretend malloc is a paddle. Every time the program uses it then it will get spanked. The free() function is "free" (pun intended) but it should be avoided because it makes you feel good about using malloc() again even though its just another spanking.

In other words don't use malloc() for god sakes. Its evil in the world of optimizing. Its fine to use once in a while, but NEVER as part of a loop, holy crap.

> The point is to shrink the array so that iterating over it each loop does not take an increasingly large amount of cpu cycles or time.

Iterations are evil as well. Any time you have to ask a redundant question, that kind of shit takes time away from your program.


So the bottom line here I think is that you are wasting valuable program time with malloc() which is pure evil. Just expand an array with references in blocks, never free it (unless the program is closed) and keep recycling memory. Your program will thank you for it.

You're complaining about C? Oh boy.

I have a Delphi project to do that involves taking files with thousands of lines of code, each file holding a dozen or more classes, some with nearly 40 "methods" (procedures), and changing them to use a different graphics interface technology. Shit's at once awesome and perfectly intractable. The original code was created by a dozen different programmers, each with their own coding style, working over a decade with the old technology.

Son, learn to love your C pointers, it's such a clean and easy language to work with...

I know what you mean.
I'm a Programmer myself and all this script languages suck ass.
I do HTML codes and stuff. Like hacker stuff and so on.
Pointers suck also but sometimes you need them to change the look of the cursor.
So I can relate to you my friend ;):)

On a final note, I think the main problem in your program is indirectly related to malloc(). If you learn to avoid using it it should automatically fix your main problem which is the iteration of disjoined pointers. When you convert your code to assembly I bet you will see lots of steps involved to stage the next iteration. If you used a flat array you'd find a huge boost in performance since you are only updating the index.

So I could just allocate a couple megabytes for every possible (predicted) instance of my object and that's all finny dandy? But that's guesswork and comparable to black magic witchcraft!

Optimized programs that need enormous variable arrays (like databases) will create a small array of pointers to blocks of flat memory arrays. That way you only use malloc() every 256 elements for example, so the performance hit is 1/256th of what it would have been if it was one big dynamic array of pointers.

No doubt this configuration is a pain in the neck to code but if speed is your game then that's one way to deal with the problem.

You can also find inspiration in file system tables which are exponentially more complex since they are trying to optimize addressing of terrabytes of data for a dynamic set of files. Fun stuff.

There is no way to predict which loop cycles will add.

I don't understand what you just said.

Optimizing code does require some understanding of the typical strains of an application, where certain places can be improved for one technique or another, or perhaps left alone if its correctly purpose built for its function. But consider that to optimize code you have to do a little bit of prediction and work around those possibilities so the CPU works less hard for the "typical" situations. It doesn't mean it will be best in all situations, but when optimizing you care more about the typical situation. There are some exceptions (like in enterprise cloud systems) but for most situations typical predictions can go a long way.

I haven't programmed in C in years but what I got out of this is that you're doing an optimization for a loop inside a loop and your performance degradation is linear. Is that correct?

Think about that for a second.

Basically what you just did is add a step to your routine that says "if the performance drops by one, add one". This is, in a loop, would mathematically cause linear performance degradation.

You need to run a loop, then exit the loop to optimize.

Nope. There is a 50% probability that an object should be added.
Beyond that the predictions would involve advanced heuristics.

Then again the probability is never zero, so basically I could allocate a couple megabytes of memory (just for good measure) and have at that.

I'm a script programmer, and guess what? We get paid the same. We're like public health policymakers versus physicians. Telling people what we do sounds less glamorous, but we have a much bigger impact than compiled code software developers.

I automated our entire build/test/deploy process four years ago. We now have over 700 pipelines running 24/7, I alone saved over half a dozen FTEs. That's more than half a million a year in my city.

My colleague automated our IDM and SSO client process, and another colleague moved our 500 server company to a private cloud and automated our server provisioning process.

Im not saying perl/python/bash/chef/ansible/docker/etc are more DIFFICULT than compiled languages, we just work faster, can do entire projects alone in a short period of time, and per person, we have a bigger impact on our company's bottom line.

Keep telling yourself that.

>2016
>ADA
Wow you must be working on those brand new 56K RAM 2MB Tape-storage cutting edge machines!

>yfw op is actually working on machines which do cut edges

What I'm saying is that you need to predict the typical expectation of a function before you can optimize it.

So in your case its "50% probability that an object should be added". That's what I'm talking about.

If you posted some of this code I think it would be a little easier to point out the flaws.

Having spent most of my professional career optimizing code, its hard to imagine all the flaws you might have because I avoid them so actively. In other words its hard to imagine someone actually writing unoptimized code on purpose, and I'm not a teacher nor have I had any formal training on the subject of best practice.

Ivy league compsci student graduating in like any day now here.

All you you bedroom programmers can kill yourselves.

I write programs that can write programs.

Until such time comes that you can write a complete compiler in Haskell or optimize code in Java using your own grammar dont talk to me.

Fucking plebs.

Nope, its a measureable result. I dont have to convince myself of anything. My job is worth 250k to 500k in productivity, our developers are worth 150k to 200k in productivity. Its in our PM resource planning allocations. My job is easier, and I and our script/sql devs get paid 15% more than our C and java devs.

Sure.

pastebin(hurg)com/KK3Q7nBL

Fuck off.

Ada 2012 is what I use in my day-to-day coding. Its a modern object-oriented language unlike Ada 83 which is what I think you are referring to.

I use it for enterprise systems where peoples lives are at steak. In other words a bug in the system could cause a door to kill a person or cost millions of dollars of damage. So yeah, Ada is literally the only good way to assure that.

You can do mission critical coding in C and other languages, but in my opinion they are inferior to Ada for many reasons.

No no no you dont get to tell me to fuck off with your first year code monkey shit.

Do you even lambda calculus pleb?

Well as long as peoples lives are not at steak. I'd hate to see people get roasted like that.

Yeah.

What do you mean by "cleanup" routines senpai?

Hey, columbia class of 2008 here.

memory management
some languages do it for you (ie .net)
others dont (ie C)
I think you're best bet is to go back to jacking off to ponies little girl

You could try multi-threading

What is the name of the array that you have been asking about?

Sad that people like this exist.

You sound like the kind of person I would be glad to hire.

>columbia
kys

I also works in Delphi with a hundreds of thousands of lines written by dozen of beginners during the past 10 years... I feel you my friend

I could go for one right about now.

>Sad that people like this exist.
If it wasnt for people like us you wouldnt be here doing this.
We're the real deal.
Not bedroom programmers and script kiddies.
I put blood and tears into my degree to learn computer science from a very highly regarded university.
I'm allowed to be a bit of a dick.

Okay I didn't write my question correcty

>It is one rule of optimizing that you avoid "cleanup" routines wherever possible

Why should one avoid cleanup routines wherever possible? I don't jack off to ponies anymore btw

Every program, regardless of length, has at least one unnecessary line.

Additionally, every program has at least one bug.

Therefore we can conclude that every program can eventually be reduced to one line that does not work.

[spoiler]SPIKE DIES![/spoiler]

>lives are at steak
>steak

who said you should avoid cleanup routines?

Did you say steak?

we know who posted this

I've seen overconfident programmers make overconfident mistakes that cost lots of money and all they do is overconfidently give excuses I don't want to hear so I overconfidently fire them.

>It is one rule of optimizing that you avoid "cleanup" routines wherever possible
Or maybe I misunderstood that sentence... ?

If you don't make messes, you don't need to clean them up. Its a concept that works in real life too.

next we will be talking about tabs over spaces

Nice dubs.

If I can write an A.I. program that can correctly tell if a person will be diagnosed with diabetes with %99.7 accuracy to you I say fuck you chump.

Name a few advantages?

Honestly just curious

THANK YOU user

Fuck I had way too much trouble understanding that

playerprojectiles

It isn't exactly complicated to clean up memory you've allocated. Automated garbage collection is nice and all but it leads to complacency and laziness in managing your code.

Well, I bet you will do well financially before you overdose on cocaine and die. But I personally value good people with solid experience over overcompensating people with fancy decorations. End up with dedicated and loyal workers who value self-improvement and avoid stupid mistakes because they love what they do. I find the overconfident ones feel entitled and make too many mistakes to have to clean up.

Thank you too user, that's what I wanted to know!

The Ada compiler is like artificial intelligence. Freaky shit. It will point out bugs you wouldn't even have found during runtime testing. I actually enjoy hitting the compile key just to see what amazing prediction it will make next about the code I just wrote. Its so fucking amazing.

The C compiler will bend over backwards just to please you. It will try not to bother you even when there are tons of problems. You'd have to use special tools and even then its light-years away from the Ada compiler's ability to catch bugs. Of course the down side is that it takes longer to see your program in action because it can take LITERALLY weeks to appease the Ada compiler so it will let you finally see the program run.

Oh, and pragma restrictions! That's one of my favorite advantages. Not to mention the powerful contract system! (oh, and SPARK).. I can go on and on.

Dont flatter yourself. THe people who will be hiring me arent on Sup Forums buddy.

I am cringing by seeing your liberal use of malloc and free. Unfortunately I don't have any more time to spend on this subject. I gotta leave in a few minutes.

noob

I'm only here for the porn and nobody knows it! MUHAHAHA

what kind of things, like unreachable code?

How are pointers hard or annoying? Aced that shit many years ago at university, and i was drunk for most of it. I'm drunk now. Just have good clean up procedures when you delete a data structure and don't lose track of shit you are creating.

Can you figure out why my program keeps getting slower?

I suggest a few bottles before opening this link.
pastebin x com/KK3Q7nBL

No need to act like a child.

Maybe this might help you. Its a link to a document that explains various techniques that could be used to avoid malloc and free.

I only had a passing glance at it so I hope its useful.

pastebin(hurg)com/ARLef6qV

Internal fragmentation.

If your objects are all the same size, allocate a whole chunk of memory yourself, and allocate them yourself on that chunk, a-la Linux's slab allocators.

If they're not, look into generational garbage collection, a-la Hotspot JVM.

Well that's one. It can predict things like bad data, or the possibility that a user might break a section of code with a certain input, or infinite loops, or loops that might crash, etc etc.

The language itself forces you to write code in a way that is very hard to break. For instance strings don't have a NULL ending character, they are fixed length. So you can't inject viruses into the system through an overflow. There's lots of things like that.

But the garbage collection bit at the end fixes that every 1000 or so cycles.

while (i > 0) i++;

When you stop the world, reallocate your entire array and fill it in order. Your pointers can be accessed sequentially, but your objects can't, which is what's leading to performance degrading.

Alternatively, use a linked list like god intended, or find someone with an actual CS qualification.

Oh shit, so I should just use an array of objects instead of pointers? What the actually that does make sense.

Oh, FFS.

You're using an array as a hashtable, and complaining that lookups are O(n).

Use a hashtable.

you must be shit at your job then

Are your objects all the same size? If so, yes, use an array. Google "slab allocator".

Note that a good C compiler, such as the one in Xcode, can do this too.

>complacency and laziness
Which, of course, has a massive impact on the deliverable.

Everyone knows that things that took more effort work better, because the universe recognises hard work and rewards you for it.

Do you still use crt monitor?

I know at least two other people at my office who are on Sup Forums. There are a lot of non-commenting visitors who come to look at pictures/porn.