The Big Programming Thread - Page 991

Prev 1 989 990 991 992 993 1032 Next

Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks.

Blisse

Canada3710 Posts

January 22 2019 10:35 GMT

#19801

On January 22 2019 04:38 SC-Shield wrote:

Show nested quote +

... HR warned me before that he had weird sense of humour ...

omg so many red flags

I'm so glad I work at a company with ... nice people. Don't settle for companies like that.

Excludos

Norway8263 Posts

January 22 2019 11:10 GMT

#19802

Honestly recursion is a fucking mess. I get that it looks cool, and in certain mathematical function it definitively makes sense, but it's a mess to look at, and a nightmare for any second hand person coming in to maintain your code later. I avoid them like the plague

SC-Shield

Bulgaria862 Posts

January 22 2019 11:22 GMT

#19803

On January 22 2019 01:15 Mr. Wiggles wrote:

Show nested quote +

Not an article, but the book "Advanced Programming in the UNIX Environment" by W. Richard Stevens has a very good treatment of many UNIX systems programming concepts. There's an entire chapter on each of the subjects of signals, threads, and thread control.

I believe there's source for the book available so you can theoretically make your own PDF if you don't want to buy it.

http://www.apuebook.com/apue3e.html

I was reading about reader-writer locks and realised that C++17 introduces shared_mutex which is quite nice to have something more portable than POSIX. Based on my understanding, this is how it works in C++.

Readers and writers have access to the same mutex which is shared_mutex.
If a thread is a reader, it's expected to use shared_lock. Obviously, data isn't supposed to be modified then. If a thread is a writer, then it's expected to use unique_lock (not shared_lock).

Example: https://en.cppreference.com/w/cpp/thread/shared_mutex

Manit0u

Poland17774 Posts

January 22 2019 11:25 GMT

#19804

On January 22 2019 19:35 Blisse wrote:

Show nested quote +

omg so many red flags

I'm so glad I work at a company with ... nice people. Don't settle for companies like that.

Nice HR department though. I wish someone warned me beforehand that most of my coworkers will be ultra-catholic and such. Not that big of a deal but it is a bit disturbing since I've always viewed programmers as less religious (and now I must hold back on some jokes and comments while in the office lest I get into another pointless debate on "How do you know right from wrong without God?!").

Acrofales

Spain18326 Posts

January 22 2019 12:33 GMT

#19805

"I read the same book you did, I just don't think it was the word of God"

Excludos

Norway8263 Posts

January 22 2019 15:46 GMT

#19806

On January 22 2019 21:33 Acrofales wrote:
"I read the same book you did, I just don't think it was the word of God"

Hitchikers guide to the galaxy? Pretty sure those be the words of god..well, a god

WarSame

Canada1950 Posts

January 23 2019 02:08 GMT

#19807

On January 22 2019 18:21 Manit0u wrote:

Show nested quote +

It is easy to substitute simple looping with recursion. But then you can potentially run into a couple of problems:
- if your language doesn't support TCO you will run into performance issues
- if your language does support TCO you can't debug it properly since you lose the stack trace

Recursion will also be a real mess for cases like that:


outer loop
  outer a

  inner loop
    inner a

    if condition
      continue outer (without going to outer b)

    inner b

  outer b

Edit: This too depends on a language of choice of course. Some make looping easier for you.

I'm wondering, though, couldn't you redesign this code?


outer_loop:
    outer_loop_logic()

outer_loop_logic():
    outer_a()
    val = inner_loop()
    if (val == null) outer_b()

inner_loop():
    val = null
    inner_a()
    if (condition):
        val = something
    inner_b()

This way you have each function only doing one thing and you have no unexpected jumps within your code(your only jumps being function calls, returns and regular control logic). I'm thinking this in particular because at work I have to deal with continues nested inside a 150 line loop which is in a loop which is in a loop... which loop is getting continued? Who knows?

tofucake

Hyrule19224 Posts

January 23 2019 04:13 GMT

#19808

You should? continue (in languages that support levels of it) defaults to 1 (current loop) and ascends from there. In languages without levels, continue affects the loop it is immediately inside of.

All you've done with that code is rewrite some while loops into do loops but hiding the fact by using function calls.

WarSame

Canada1950 Posts

January 23 2019 04:15 GMT

#19809

But hasn't that made it easier to read and reason about?

tofucake

Hyrule19224 Posts

January 23 2019 04:54 GMT

#19810

No, it's made everything disjointed. It looks fine in pseudo code but in actual practice things are a lot more complicated

Manit0u

Poland17774 Posts

January 23 2019 09:13 GMT

#19811

On January 23 2019 13:15 WarSame wrote:
But hasn't that made it easier to read and reason about?

You've also made a mistake there. In your inner loop when condition is met you must now return some magic value (and not proceed to inner b) to make outer loop logic aware that it should skip over to the next iteration (and null isn't really good for that since it's default return value for functions most of the time).

So, using recursion this code would look more like that:


rec_outer(args)
  if end_condition
    return

  outer a

  result = rec_inner(args)

  if result == magic
    return rec_outer(args)

  outer b

  return rec_outer(args)

rec_inner(args)
  if end_condition
    return

  inner a

  if condition
    return magic

  inner b

  return rec_inner(args)

Now tell me which is more readable to you... Especially that in recursion you now need to pass extra args around everywhere to control it whereas in loops it's all abstracted away.

spinesheath

Germany8679 Posts

January 23 2019 17:09 GMT

#19812

Realistically there are cases where continues/breaks are better, and there are cases where you can restructure the code and make it better that way. Ideally you just try both options and choose the one best suited for your particular case.

In practice, you randomly choose one and maybe clean it up a little.

Also don't forget that there sometimes is an option to refactor that kind of nested loop in a completely different way (rather than just wrapping loops into functions). For example you could attempt to first create a (lazily evaluated) sequence of tuples (a, b), then filter those tuples, then work with the rest. Not always the best choice, but sometimes just so much better.

Manit0u

Poland17774 Posts

January 24 2019 01:23 GMT

#19813

In practice whatever works best in current situation is usually what ends up being used. No matter how "ugly" it might be to the purists.

WarSame

Canada1950 Posts

January 24 2019 02:17 GMT

#19814

Okay, I accept that! So this hasn't entirely changed my view but I can definitely agree that both are valid in their own use cases. Thanks for the discussion!

Manit0u

Poland17774 Posts

January 24 2019 09:32 GMT

#19815

https://www.theregister.co.uk/2019/01/22/google_chrome_browser_ad_content_block_change/

Edit:

Heh, I got myself into a nice mess... Got a task of investigating some users missing rewards for the ads they've watched. We have over 4.5 billion users in our db and there have been 2.7 billion reward attempts this month.

Time to put my SQL goggles on.

enigmaticcam

United States280 Posts

January 24 2019 16:24 GMT

#19816

On January 24 2019 18:32 Manit0u wrote:
https://www.theregister.co.uk/2019/01/22/google_chrome_browser_ad_content_block_change/

Edit:

Heh, I got myself into a nice mess... Got a task of investigating some users missing rewards for the ads they've watched. We have over 4.5 billion users in our db and there have been 2.7 billion reward attempts this month.

Time to put my SQL goggles on.

Temp tables with indexes!

Manit0u

Poland17774 Posts

January 24 2019 23:20 GMT

#19817

On January 25 2019 01:24 enigmaticcam wrote:

Show nested quote +

Temp tables with indexes!

I work for a company that has the biggest mysql db in europe and due to traffic and response times requirements they got rid of stuff like indices and shit (with large enough tables indices slow you down).

I'm in the 20-30 minute wait to discover this was not the query you were looking for territory...

JimmyJRaynor

Canada17642 Posts

January 25 2019 01:17 GMT

#19818

What exactly slows down due to the presence of indexes? a search for a single record? a certain type of query?
Normally, adding new records gets slower as one generates more indexes for a table.

what size of table starts to see these "slow down" issues?

i'm a microsoft guy. i know very little about mysql.

Lmui

Canada6223 Posts

January 25 2019 08:08 GMT

#19819

On January 25 2019 10:17 JimmyJRaynor wrote:
What exactly slows down due to the presence of indexes? a search for a single record? a certain type of query?
Normally, adding new records gets slower as one generates more indexes for a table.

what size of table starts to see these "slow down" issues?

i'm a microsoft guy. i know very little about mysql.

Just points that apply generally for every database

Updates/Inserts are slower with more indexes since they're traditionally duplicates of data in existing tables.
Anything requiring a lock for read/update on anything other than the full table also slows dramatically as you add indexes since the indexed rows need to be locked as well.

Reads on non-* queries are generally faster if they're using fewer columns than are in the full table.

Before you hit 100s of gb, you should've already optimized the shit out of the structure of the database, and determined the architecture of your DB for 5+ years. Hard to say when the query starts slowing down since it's a fairly steady increase in query time with db size.

As much as I hate to say it, you get what you pay for. Using full blown Oracle (Literally costs 10+ million a year at this scale) instead of mysql, or any of the other databases which are proven to scale to petabytes (SQL Server, SAP HANA etc.) is what this use case helps a lot with. Odds are if you did, the query would probably still be in the 10s of seconds to low minutes range. This is especially true if you are using database instances that fit within memory of a few giant servers (low 10s of TB).

Acrofales

Spain18326 Posts

January 25 2019 14:31 GMT

#19820

On January 25 2019 08:20 Manit0u wrote:

Show nested quote +

Why don't you take a slice, figure out the query you want on the slice, and then once you got it mostly debugged, execute it on the full DB? There'll probably still be some bugs due to weird corner cases that weren't in your slice, but at least you won't have to wait 20-30 minutes *every* time you want to test a query.

Prev 1 989 990 991 992 993 1032 Next

Please or register to reply.

The Big Programming Thread - Page 991

Completed

Ongoing

Upcoming