how the process and threads performance will vary according to timslice.(how much time will approximately take to execute).in which situation we will use threads instead of process.
I'd like to rephrase your question as this: In what cases should a single application multiple threads, and in what cases should it use multiple processes instead?
In this question, time slices don't matter at all: operating systems today only schedule threads, and treat a "plain" process as having a single thread.
What does matter performance-wise is the creation overhead: creating a process is typically more expensive than creating a thread. Multi-processing applications avoid this cost be using pools, i.e. they create new processes only rarely, but reuse them when done with some task. As thread creation is still expensive, people often do the same with threads.
What also matters is communication overhead: in threads, you can easily share memory; in processes, you typically copy things (e.g. using a pipe). There are ways to share memory across processes as well, but those are fairly difficult to use.
So in general, threads should be faster than processes. Why people still use processes? Because they are the simpler programming model. Because of the shared memory in threads, it is very easy to make mistakes, and have libraries/APIs that are not thread-safe. Lack of thread-safety can be circumvented by using processes.