Hi,
We have a textarea which has huge data inside, when we try to edit something within it, the speed is very slow, is there any way to make the editing speed faster?
What are you doing w/ 30-50 pages in one textarea?
Programming today is a race between software engineers striving to build better and bigger idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook (No, I'm not Rick)
faraway - if you spend some time reading threads here, you will see that I am generally fairly helpful. As it stands, I cannot picture a web based application that has a text area which needs to hold 30-50 pages. To that point, I'm not sure what you're doing and why. Answering those questions help me help you. Thanks for the dose of attitude.
Programming today is a race between software engineers striving to build better and bigger idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook (No, I'm not Rick)
Actually we use <div contenteditable... and textarea to work as editor, sometime the content is very large and the editing speed is very slow. But in Word, even content is huge, it still can be edited very fast. So we just think whether we can change some attribute of div or textarea to make it can be edited much faster.
>> So we just think whether we can change some attribute of div or textarea to make it can be edited much faster
Unfortunately this is governed only by the processing power and available RAM on the machine doing the editing. I've had similar problems with clients who complain that my web applications run slowly on their PII clunkers.
Never be afraid to share your dreams with the world.
There's nothing the world loves more than the taste of really sweet dreams.
your textarea / div tries to hold all the content in memory at once. Blame your browser for avoiding loads as you scroll a textarea
Word on the other hand probably just puts in memory the current and page and the 2 adjacent ones. It can handle 1000 page docs this way.
There probably is a way to split it up logically. How about paging? So if there are more than say 10k chars in the div/textarea you load the current 10k and offer next-page prev-page links to the rest of the content.
Yep, I agree that you're talking about seeing effect from a combination of individual processors and simple smackdown on the textarea input widgit. One of my applications is a JavaScript calculator and on occasion we shove many thousands of characters in those poor widdle textareas. They handle it, but with nowhere near the facility of, say, a compiled executable with a rich-edit component.
So, comparisons against Word aren't really fair.
I've been bouncing against a similar issue obliquely while working on a pure JavaScript word processor.
I guess the short answer to your question is:
[ol][li]Make sure your user is aware that operating speed is heavily dependent upon their own client-side configuration.[/li][li]Make darn sure that your algorithms are as speedy as they can possibly be.[/li][/ol]
Cheers,
Edward
"Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door
HTML forms aren't really designed to manipulate large documents. If they do so slowly and under protest you should take that as a hint!
Are you sure that a textarea is the only way to do what you want to do? Could you not have your users prepare the document in Word (or whatever) and upload it using a <input type="file"> control? Alternatively, maybe you can find a Java applet that handles large documents better.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.