Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Pers-split() in C

Programming languages, Coding, Executables, Package Creation, and Scripting.
Post Reply
Message
Author
eState
Posts: 2
Joined: 2015-10-05 14:03

Pers-split() in C

#1 Post by eState »

Hi All.
I want to create alternative of PERL-split() function.
But I've encountered with two problem.
1. It's necessary to get number of separators entities in input string.
2. It seems that there should be some check for last char. It's necessary to get it
I guess that this problems are easy to solve. But loops(for separator entities counter and getting last char etc.) obviously will lead to performance decrease. And of course it's to complex solution, It's no a true-C-way, I guess. Is there another way?

Thanx a lot!

User avatar
dasein
Posts: 7680
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: Pers-split() in C

#2 Post by dasein »

Homework assignment?

User avatar
Rando
Posts: 1
Joined: 2015-10-05 21:49

Re: Pers-split() in C

#3 Post by Rando »

Hi.
1. Count separators entities number could be obtained without a loop. Using just recursion.
2. Also there is no need to get last char with a loop.
3. What is your purpose to reinvent the wheel?;)
you can use this code.

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Pers-split() in C

#4 Post by tomazzi »

eState wrote: But loops(for separator entities counter and getting last char etc.) obviously will lead to performance decrease
Rando wrote:Count separators entities number could be obtained without a loop. Using just recursion.
Recursion is not faster than loops - it's definitely slower. For small functions recursive calls are horribly slow, that is, the time needed to save caller's context is longer than the time needed to execute actual code. For relatively big functions, recursion is still slower than loops - because the time needed to save caller's context is still much longer than the time needed for checking the exit condition for a loop.

On the other hand, many today's CPUs have the ability to execute code out-of-order, what reduces the cost of conditional jumps (thus also loops) almost to zero.

Recursion only makes sources looking "nicer"...

...definitely a homework ;)
Odi profanum vulgus

eState
Posts: 2
Joined: 2015-10-05 14:03

Re: Pers-split() in C

#5 Post by eState »

Thank you guys. That is not homework:) Just curiosity.
I've never thought that loop could be faster....Recursion looks very nice....

tomazzi
Posts: 730
Joined: 2013-08-02 21:33

Re: Pers-split() in C

#6 Post by tomazzi »

eState wrote:Just curiosity.
I've never thought that loop could be faster....Recursion looks very nice....
In fact I was curious too - I've wondered if this topic can become more serious ...or not ...

Recursion has one very nasty property: it uses stack to save/restore caller's context - therefore this techniqe needs some mechanism to control nesting depth or in other words: a mechanism which will prevent stack overflow. This of course will cost additional time...

But, most of programmers are completely unaware of another fact, related to stack: Today, all operating systems are allocating virtual memory for each process, usually it defaults to something like 1MB or 1GB. It doesn't matter however, how much virtual memory is allocated - this is a kind of a "declaration". Physical memory is limited - so if a program will eventually need more memory than usual (assumed by the OS, or due to deep nesting of function calls), then 2, quite possible possible scenarios can totally kill the performance:
1. the stack can be re-allocated - about 100-200us on modern x86 CPU systems.
2. the stack memory can be loaded from a swap file (extremely bad case, forget it)

(1) 200us may seem to be a very short period of time - it's only 200*10^-6 seconds - but for a CPU it's just a disaster - a 1GHz x86 CPU can execute up to 1000 instructions per 1 microsecond ... - this means 100...500 lines of C code at least (typically).

Regards.
Odi profanum vulgus

Post Reply