Hello. Recently, a friend of mine moved to Japan, and he was
complaining about Firefox's sluggishness relative to WebKit-based
browsers. He could not switch to Chrome because he frequently used the
extension called rikaichan for Firefox, so I offered to recreate it
for him on Chrome/Chromium. I made it specifically for him, but I'm
sharing it in case anyone else is interested.

I named the extension jdic-chrome, and created a repository on GitHub:
http://github.com/tumult/jdic-chrome

Screenshot:
http://files.chip.vg/jdic-chrome-screenshot.png

You can download a packed (.crx) version of the extension here:
http://cloud.github.com/downloads/tumult/jdic-chrome/jdic-chrome-build.crx
[13.5mb]

Please note that I do not know Japanese, so I cannot offer any help on
any requests that require knowledge of the language.

I may not update this file regularly, so in the future you might want
to download it from source or check the GitHub repository for updates.

It currently lacks many features other people may find useful. You can
see the list of problems on the GitHub repository.

The only interesting technical problem currently faced is the very
high memory usage of the dictionary data. It exists as a very large
set of JSON objects, preprocessed from the EDICT file format. Once
loaded, the size bloats by about 10x. It appears to be outrunning the
garbage collector. Forcing garbage collection (via opening the
inspector and connecting the V8 debugger) reduces it by half, but it
still remains around 130mb. Loading the data as JSON parsing on XHR
requests was worse than including .js files with the objects in them,
both in terms of loading speed and memory usage.

I considered creating a separate index and holding the contents of the
dictionary in memory as a large string, but I was more concerned with
CPU usage than saving 50mb. If I had more inclination to work on that
problem, it might have been worth profiling to see the difference in
terms of lookup speed. With the current method, the cursor can be
tracked and words can be looked up at ~50ms intervals with a minimal
CPU hit (on the background page which is actually doing the lookups,
that is. The animated bubble and DOM selection setting uses a fair bit
on the client pages.)

Another solution would be to use NPAPI and do it in a much more
efficiently in a plugin, but I wanted to try something quite goofy and
fun with JavaScript, and it ended up working out ok.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Chromium-extensions" group.
To post to this group, send email to chromium-extensions@googlegroups.com
To unsubscribe from this group, send email to 
chromium-extensions+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-extensions?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to