Does shorter sprint(eg : 2 weeks) has more overhead than the longer sprint( eg: 4 weeks)?

Using the maximum allotted timeboxes per the Scrum Guide, in a 4 week / 1 month Sprint, assuming that each Scrum Team member participates in all events, each person would spend at most 8 hours in Sprint Planning, between 4.5 and 5 hours in Daily Scrum, 4 hours in a Sprint Review, 3 hours in Sprint Retrospective, and 80 hours performing refinement. This is a total of 99.5-100 hours in Scrum events per Sprint, out of a total of 800 hours in the Sprint, or about 1/8 or about 13% of capacity.

Assuming that each event is scaled down proportionally for a shorter sprint, during a 1 week Sprint, each person would spend 2 hours in Sprint planning, between 0.75 and 1.25 hours in Daily Scrum, 1 hour in Sprint Review, about 1 hour in Sprint Retrospective, and about 4 hours performing refinement. This is about 20% of a person's normal work week.

I made the assumption that all Scrum Team members participate in all events equally, which is not necessarily true. For example, the Daily Scrum is primarily for the Development Team and may not need the attendance of the Product Owner and Scrum Master. It also assumes the full timebox is used for all events, which also may not be true. This also only accounts for spending time in Scrum-mandated events and activities and not other coordination events.

I'd point out that the relative time spent in events isn't that different, especially as teams mature and understand the purpose behind their events and get better at executing them. Rather than looking at overhead, you should consider the ability of the team to do work that is worth getting feedback on. In some cases, stakeholders outside the team simply cannot provide feedback on a weekly cadence, so 2, 3, or 4 week cadences allow the team more time to do more work and have a larger set of work to review and get feedback on. However, this also does increase the risk of the team doing the wrong work and needing to course correct. So it's all about tradeoffs.

Thanks Thomas for replying.I want to know why you assumed hours spent on backlog refinement for 4 weeks sprint is 80 hours and that of 1 week sprint is 4 hours.Why there is a huge difference between the two and why it is not scaled down like other scrum events.

Not going to put words in @Thomas' mouth but notice that the Scrum Guide says:

Refinement usually consumes no more than 10% of the capacity of the Development Team.

Given the total time for Sprints of differing length his calculations are much clearer.  

Hope that helps. 

How short sprints has more overhead than the long sprints.

Does the administrative overhead required to hold a good, productive event scale linearly with the time-box allowed for it?

I think we should be careful when we talk about the overhead of any sprint length, or any way of working.

This kind of question often leads to talk of efficiently utilizing the time spent on various initiatives; without necessarily discussing how effective that is.

It might be that 2 week sprints involve more context switching, and more time spent in meetings. I'm more interested in what can be achieved within 2 or 4 weeks (or any other length), and whether a certain sprint length provides better opportunities to learn more quickly and change direction.

Although shorter sprints theoretically allow this, having longer sprints can allow for more outcome focused Sprint Goals, and provide better learning opportunities.

Being able to inspect and adapt is generally more important than maximizing the amount of work done or product developed.

Thanks Thomas for replying.I want to know why you assumed hours spent on backlog refinement for 4 weeks sprint is 80 hours and that of 1 week sprint is 4 hours.Why there is a huge difference between the two and why it is not scaled down like other scrum events.

I based it on the 10% of the Development Team's capacity. However, I also totally botched the math for the 4 week Sprint. Assuming a 40 hour work week, there would be 160 hours in a 4 week Sprint. 10% of 160 is 16, not 80. This results in 8 hours for Sprint Planning, 4.5-5 hours in Daily Scrum, 4 hours in Sprint Review, 3 hours in Sprint Retrospective, and 16 hours performing refinement activities. This results in a total of 35.5-36 hours of allocated activities, which is about 23% of capacity. This makes it even closer in total capacity to the time spent in a 1 week Sprint in terms of effort.

However, as I mentioned in my last paragraphs, I would also like to concur with Simon Mayer's thoughts. There are more important things than overhead, and that's the ability to synchronize with business events and with external stakeholders. What makes the most sense for the team to produce something that is worthy of inspection by external stakeholders?

Even if it costs more in overhead, you get faster feedback with shorter sprints. Faster feedback means more effective product increments and higher value. 

Valuable points mentioned in the arguments above. I'd like to add that the longer the duration of the sprint, the higher the risk of either stakeholders changing their minds, the initial planning needs to adjust on a larger scale, etc. etc. Although 4 weeks is still a short period of time, these things are more likely to happen in a 4 week sprint than in a 2 week sprint. 

On the other hand, the impact of the larger amount of work done in a 4 week sprint usually leeds to bigger "ooh's" and "aah's". So like Thomas already said, it's about trade-offs.